gstreamer hangs when accessing webcam (on specific hardware)

Extra log files in case they are useful.

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/966294

A second attempt without triggering the install from the live CD ended up in a hung machine as well. Unable to go beyond the screen that asks for user name and machine name, password, etc.

This time, the /var/log/installer/debug file shows a different error:
** (ubiquity:3053): WARNING **: The connection is closed

(ubiquity:3053): Pango-WARNING **: error opening config file '/root/.pangorc': Permission denied

Error opening file for reading: Permission denied
Error opening file for reading: Permission denied
update_release_notes_label()
update_release_notes_label()
Home directory /home/ubuntu not ours.
Home directory /home/ubuntu not ours.
Home directory /home/ubuntu not ours.

Attached a second set of logs, from the same test machine.

Adding gdb information while ubiquity is stuck, at different points in time. Additionally one set with debug symbols loaded for most libraries (ubiquity.gdb-bt.txt) and some context information of what is passed from ubiquity_webcam_play to the gst functions.

Finally managed to run valgrind (memcheck) and get a log out of it.

strace of open and ioctl attached.

Status changed to 'Confirmed' because the bug affects multiple users.

Also effect me on my system HP G62

details can be found at http://davmor2.co.uk/pc-specs/main-laptop.html

This problem also happens when trying to activate the camera with cheese.

So, do you think this is a bug with cheese or ubiquity? I have a webcam on only one machine (an MBP1,1) and running cheese from the command line on an installed 12.04 seems to work fine.

What happens if you run `cheese` from the command line on a live CD when you "Try Ubuntu"?

gema tracked it down to be a problem in gstreamer. Moving it there.

Same behaviour than with ubiquity. The application never comes up and it eats all the CPU and eventually the system runs out of memory.

I think the bug is in either gstreamer or the kernel, because there is a ioctl call that seems to "point to uninitialised byte(s)".

On Thu, Mar 29, 2012 at 02:46:13PM -0000, Barry Warsaw wrote:
> So, do you think this is a bug with cheese or ubiquity? I have a webcam
> on only one machine (an MBP1,1) and running cheese from the command line
> on an installed 12.04 seems to work fine.

At its root I'm sure it's a bug with cheese, but it may be that ubiquity
needs to be more robust in the face of cheese failures, too?

This is probably the same issue as Bug #909179

A temporary work around to get the installer to progress is to run the following command in a terminal before running the installer.

sudo rm /usr/lib/ubiquity/plugins/ubi-webcam.py

Bug confirmed on a Samsung NF310 (Shark)
Using ISO 10.04 Beta 2, moved to a USB stick using Ubuntu usb creator

Ubiquity seems to be failing when clicking on Next, after entering 1st user (admin) informations.
No matter if files copying just started, or if I am waiting all files to be copied: when clicking on Next step.
No matter if wifi is connected or not, and if "download upgrade when installing" is checked or not.

Will try "sudo rm /usr/lib/ubiquity/plugins/ubi-webcam.py" tonight before launching installation.

I am replying to this bug, as all other duplicates are not assigned, and a workaround has been provided with this bug.

Just 2 things:
- Duplicate Bug #909179 is assigned to "Canonical Foundations Team", which is a bit confusing.
Who is really working on this bug that we may help ?
- This bug is tagged as high, unfortunately not Critical: BUT IT SHOULD !
According to all duplicates, showing issues on many laptops (from many vendors), it is blocking many users from being able to install Precise !

Just have a look at this:
http://www.zdnet.co.uk/blogs/jamies-mostly-linux-stuff-10006480/ubuntu-1204-beta-2-i-still-dont-like-it-10025792/
"However, it would not load on the Samsung NF310 - it gets to the step where it should want me to choose a picture for my account (or take a picture with the built-in camera) and it just hangs forever. I have no idea why"

Cheers
Fred

Added a task for ubiquity to make it more robust against webcam issues.

Steve, ubiquity uses gstreamer directly, not via cheese. cheese is just another example of an application that runs into the same problem.

Does anyone have any realistic proposals on how ubiquity might be made more robust in this specific case? I can't think of anything. It's a gstreamer bug and needs to be fixed there, AFAICS.

(Proposals: without actually removing features, I mean, which is not on the cards for 12.04.)

I think it would be better to remove the camera functionality than to release with this bug that doesn't allow installing in many systems.

Or maybe, if the screen doesn't load in however many seconds, skip the picture taking?

The latter suggestion would require introducing concurrency here, which I think would be risky. I would rather we tried to fix the gstreamer bug.

Status changed to 'Confirmed' because the bug affects multiple users.

I think it is riskier to leave that camera screen there than to remove it. And we should proceed before feature freeze.

The Desktop team doesn't have anyone that is going to be able to fix this, so I suggest you guys fix the installer to work around it.

I am not in possession of a time machine and thus cannot proceed before
feature freeze. Do you mean final freeze?

Yes, that's what I meant, sorry :)

Stéphane will have a look at fixing this properly in gstreamer.

Did some extra debugging in webcam.c initially, I tracked down the hanging call to be:

if (gst_element_set_state (priv->camerabin, GST_STATE_PLAYING) == GST_STATE_CHANGE_FAILURE) {

or more specifically gst_element_set_state(priv->camerabin, GST_STATE_PLAYING)

I also confirmed that it's a gstreamer issue as I'm unable to reproduce with "luvcview" but I don't yet know why only a few devices are affected.

Tracked down to gstreamer for sure this time, downgrading to Oneiric's stack fixes the problem.

root@ubuntu-test64:~# lsof -n | grep gstreamer
lsof: WARNING: can't stat() fuse.gvfs-fuse-daemon file system /home/ubuntu/.gvfs
      Output information may be incomplete.
nautilus 1664 ubuntu DEL REG 8,1 4203064 /usr/lib/x86_64-linux-gnu/libgstreamer-0.10.so.0.30.0
goa-daemo 1818 ubuntu DEL REG 8,1 4203064 /usr/lib/x86_64-linux-gnu/libgstreamer-0.10.so.0.30.0
ubiquity 30983 ubuntu mem REG 8,1 6176 4209420 /usr/lib/gstreamer-0.10/libgstapp.so
ubiquity 30983 ubuntu mem REG 8,1 35976 4209505 /usr/lib/gstreamer-0.10/libgstvideocrop.so
ubiquity 30983 ubuntu mem REG 8,1 135128 4209503 /usr/lib/gstreamer-0.10/libgstvideo4linux2.so
ubiquity 30983 ubuntu mem REG 8,1 69240 4203282 /usr/lib/gstreamer-0.10/libgstxvimagesink.so
ubiquity 30983 ubuntu mem REG 8,1 23472 4209471 /usr/lib/gstreamer-0.10/libgstmultifile.so
ubiquity 30983 ubuntu mem REG 8,1 40264 4209466 /usr/lib/gstreamer-0.10/libgstjpegformat.so
ubiquity 30983 ubuntu mem REG 8,1 78064 4209465 /usr/lib/gstreamer-0.10/libgstjpeg.so
ubiquity 30983 ubuntu mem REG 8,1 36264 4209441 /usr/lib/gstreamer-0.10/libgstautodetect.so
ubiquity 30983 ubuntu mem REG 8,1 68808 4209425 /usr/lib/gstreamer-0.10/libgstaudioresample.so
ubiquity 30983 ubuntu mem REG 8,1 23288 4203066 /usr/lib/gstreamer-0.10/libgstaudiorate.so
ubiquity 30983 ubuntu mem REG 8,1 65704 4203068 /usr/lib/gstreamer-0.10/libgstvorbis.so
ubiquity 30983 ubuntu mem REG 8,1 27464 4203070 /usr/lib/gstreamer-0.10/libgstvideorate.so
ubiquity 30983 ubuntu mem REG 8,1 100008 4209424 /usr/lib/gstreamer-0.10/libgstvideoscale.so
ubiquity 30983 ubuntu mem REG 8,1 333328 4209416 /usr/lib/gstreamer-0.10/libgstffmpegcolorspace.so
ubiquity 30983 ubuntu mem REG 8,1 69936 4209417 /usr/lib/gstreamer-0.10/libgsttheora.so
ubiquity 30983 ubuntu mem REG 8,1 158904 4209333 /usr/lib/gstreamer-0.10/libgstogg.so
ubiquity 30983 ubuntu mem REG 8,1 93200 4209332 /usr/lib/gstreamer-0.10/libgstaudioconvert.so
ubiquity 30983 ubuntu mem REG 8,1 57992 4209419 /usr/lib/gstreamer-0.10/libgstencodebin.so
ubiquity 30983 ubuntu mem REG 8,1 35432 4203067 /usr/lib/gstreamer-0.10/libgstvolume.so
ubiquity 30983 ubuntu mem REG 8,1 262968 4205553 /usr/lib/gstreamer-0.10/libgstcoreelements.so
ubiquity 30983 ubuntu mem REG 8,1 69264 4209446 /usr/lib/gstreamer-0.10/libgstcamerabin2.so
ubiquity 30983 ubuntu mem REG 8,1 930768 4205548 /usr/lib/libgstreamer-0.10.so.0.29.0
ubiquity 30983 ubuntu mem ...

Running ubiquity with the following packages downgrade to their Oneiric version makes it work:
root@ubuntu-test64:~# dpkg -l | grep 0.10.35
gstreamer0.10-plugins-base 0.10.35-1 GStreamer plugins from the "base" set
gstreamer0.10-x 0.10.35-1 GStreamer plugins for X11 and Pango
libgstreamer-plugins-base0.10-0 0.10.35-1 GStreamer libraries from the "base" set
libgstreamer0.10-0 0.10.35-1 Core GStreamer libraries and elements

Upgrading libgstreamer0.10-0 to the Precise version re-creates the problem. So the regression likely happened in the gstreamer0.10 source.

Post #17: Workaround is working (Samsung netbook NF310 shark):
sudo rm /usr/lib/ubiquity/plugins/ubi-webcam.py

If no solution is found, removing this file from iso will solve this really anoying bug which is affecting many laptop.

Attached is dmidecode for Samsung NF310 (NP-NF310-A01FR)
And result of lsusb command for the webcam having issue with this version of gstreamer.

Remark: after successfull install, Cheese is not working (not starting, and CPU jump to 100%)

Attached is lsusb for Samsung NF310 (NP-NF310-A01FR)
For the webcam having issue with this version of gstreamer.

For anyone else interested in tracking down this bug as I'm not going to be around until Tuesday, the current assumption is that something in the core of gstreamer is causing the regression.

As it only happens on a subset of hardware, the guess would be that it has to do with the encoding/decoding part that may take a different path depending on the pixelformat/resolutions supported by the webcams.
luvcview -L can help figuring that out.

I rebuilt Oneiric's gstreamer on Precise and can confirm that it still works. The rebuild was done keeping the multi-arch changes that were introduced in Precise, so we know for sure that it's 0.10.35 => 0.10.36 that broke it, most likely in the gstreamer0.10 source though not impossible it's caused by something wrong in -base or -good.

That same problem is still with latest night builds in ubuntu live 64 and 32 bits.
Indeed seems to be problem with laptops that have build in webcam and freezes installation on that stage, after entering user and machine name and clicking next.

I hit this just now.
chose to work around by rrmod uvcvideo and for good measure rm /lib/modules/*/kernel/drivers/media/video/uvc/uvc*.ko

Ok, I just updated the title to reflect reality.
As far as I can tell, gstreamer doesn't loop, though the gtk client certainly hangs (debug log still shows frames being processed).

I figured a "fix" for the regression by reverting part of an upstream commit: http://paste.ubuntu.com/926326/
The upstream commit in question (found through bisect) is: f56c6e12255b37d75b1eb949e434fa8e3bb33f51

I'm now attaching the logs with GST_DEBUG=5 for cheese (camerabin) and ubiquity (camerabin2) both with the revert (working behaviour) and without (UI hanging).

cheese.gz => starting cheese and killing it when it starts hanging
cheese-with-revert.gz => starting cheese, waiting for video to come up, closing it
ubiquity.gz => starting ubiquity, navigating to the webcam step, waiting for it to hang, killing
ubiquity-with-revert.gz => starting ubiquity, navigating to the webcam step, waiting for video to come up, killing

I did the tests on Gema's system, so the logs above should be accurate.
Device is:
Bus 001 Device 002: ID 13d3:5116 IMC Networks Integrated Webcam
It's a uvcvideo device, though I confirmed that not all uvcvideo devices are affected.

Here's the output of luvcview regarding that hardware:root@ubuntu-test64:~/test# luvcview -L
luvcview 0.2.6

SDL information:
  Video driver: x11
  A window manager is available
Device information:
  Device path: /dev/video0
{ pixelformat = 'YUYV', description = 'YUV 4:2:2 (YUYV)' }
{ discrete: width = 640, height = 480 }
 Time interval between frame: 1/30, 1/30, 1/30, 1/30,
{ discrete: width = 800, height = 600 }
 Time interval between frame: 2/15, 2/15, 2/15, 2/15,
{ discrete: width = 1024, height = 768 }
 Time interval between frame: 2/15, 2/15, 2/15, 2/15,
{ discrete: width = 1280, height = 1024 }
 Time interval between frame: 2/15, 2/15, 2/15, 2/15,
{ discrete: width = 352, height = 288 }
 Time interval between frame: 1/30, 1/30, 1/30, 1/30,
{ discrete: width = 320, height = 240 }
 Time interval between frame: 1/30, 1/30, 1/30, 1/30,
{ discrete: width = 176, height = 144 }
 Time interval between frame: 1/30, 1/30, 1/30, 1/30,
{ discrete: width = 160, height = 120 }
 Time interval between frame: 1/30, 1/30, 1/30, 1/30,
{ discrete: width = 1280, height = 960 }
 Time interval between frame: 2/15, 2/15, 2/15, 2/15,
{ discrete: width = 1280, height = 800 }
 Time interval between frame: 2/15, 2/15, 2/15, 2/15,
{ discrete: width = 1280, height = 720 }
 Time interval between frame: 2/15, 2/15, 2/15, 2/15,
{ discrete: width = 1280, height = 1024 }
 Time interval between frame: 2/15, 2/15, 2/15, 2/15,
{ pixelformat = 'RGB3', description = 'RGB3' }
{ discrete: width = 640, height = 480 }
 Time interval between frame: 1/30, 1/30, 1/30, 1/30,
{ discrete: width = 800, height = 600 }
 Time interval between frame: 2/15, 2/15, 2/15, 2/15,
{ discrete: width = 1024, height = 768 }
 Time interval between frame: 2/15, 2/15, 2/15, 2/15,
{ discrete: width = 1280, height = 1024 }
 Time interval between frame: 2/15, 2/15, 2/15, 2/15,
{ discrete: width = 352, height = 288 }
 Time interval between frame: 1/30, 1/30, 1/30, 1/30,
{ discrete: width = 320, height = 240 }
 Time interval between frame: 1/30, 1/30, 1/30, 1/30,
{ discrete: width = 176, height = 144 }
 Time interval between frame: 1/30, 1/30, 1/30, 1/30,
{ discrete: width = 160, height = 120 }
 Time interval between frame: 1/30, 1/30, 1/30, 1/30,
{ discrete: width = 1280, height = 960 }
 Time interval between frame: 2/15, 2/15, 2/15, 2/15,
{ discrete: width = 1280, height = 800 }
 Time interval between frame: 2/15, 2/15, 2/15, 2/15,
{ discrete: width = 1280, height = 720 }
 Time interval between frame: 2/15, 2/15, 2/15, 2/15,
{ pixelformat = 'BGR3', description = 'BGR3' }
{ discrete: width = 640, height = 480 }
 Time interval between frame: 1/30, 1/30, 1/30, 1/30,
{ discrete: width = 800, height = 600 }
 Time interval between frame: 2/15, 2/15, 2/15, 2/15,
{ discrete: width = 1024, height = 768 }
 Time interval between frame: 2/15, 2/15, 2/15, 2/15,
{ discrete: width = 1280, height = 1024 }
 Time interval between frame: 2/15, 2/15, 2/15, 2/15,
{ di...

Question for the release team:

I managed to track down that bug to a specific upstream commit, reverting the change seems to work on my test machine at least as far as the webcam part is concerned. So I'm confident uploading that change will fix the installer.

Now I'm no gstreamer expert and it's not unlikely that this revert will break something else in gstreamer. The bug has been forwarded upstream so hopefully we'll get a proper fix soon.

My question is, do we prefer to wait until upstream has a fix (can be days/weeks) before touching gstreamer or do we prefer to take the risk of regressing gstreamer to fix the installer?

My personal opinion is that it's much easier to fix whatever I break with that fix post-release through an SRU than to tell everyone affected to wait till the first point release to get a working media.

This bug was fixed in the package gstreamer0.10 - 0.10.36-1ubuntu1

---------------
gstreamer0.10 (0.10.36-1ubuntu1) precise; urgency=low

  * Revert upstream commit: f56c6e12255b37d75b1eb949e434fa8e3bb33f51
    This fixes cases where starting to play a webcam stream would
    make gstreamer (or part of it at least) hang. (LP: #966294)
    .
    Upstream bug is tracked at:
    https://bugzilla.gnome.org/show_bug.cgi?id=673991
 -- Stephane Graber <email address hidden> Thu, 12 Apr 2012 13:04:26 +0200

I have verified this fix, and the camera shows up and takes a picture and then the installation continues happily.

Samsung NF310
gstreamer 0.10.36-1 solves the problem (cheese is working fine, no more cam issue)

I tested daily build 20120415 today:
http://www.cdimage.ubuntu.com/daily-live/20120415/precise-desktop-amd64+mac.iso

No more problem during installation, after entering information about 1st user, the webcam successfully starts up, and the installation is successfull.

Well done, thanks !

Fred

I got the problem with an Asus 1005 PE and it seems fixed too.

upstream asked "Could you also get a backtrace of all threads when everything hangs?" ... could somebody having the issue do that?

It never really hung for me. What happened was that the ubiquity tread used all the CPU it could get and start eating up all the memory. After almost an hour of unresponsiveness the last bit of memory and swap was gobbled up and the ubiquity thread was killed (by 'kswap0' or something with a similar name). After that the liveCD desktop would start.

It does feel like something hangs, but the machine is actually really busy (and unresponsive).

I don't have a backtrace or the bugged .iso to reproduce the bug, sorry.

Precise beta2 isos (which contains the buggy version of gstreamer) are still available (new daily builds are OK now).
I just downloaded x86_64 beta2 iso in order to test, but have no idea what exactly means "get a backtrace of all threads"...

I agree with miegiel description, but for me, when the computer is stuck, no more responsive, it is just hanging :-)
For sure, CPU is 100% and more an more memory is used, but I've never been able to wait for about 1 hour...

Fred

I have the same issue in 12.10 ALFA2, installing after enter username, host-name.... and then going "NEXT" ubiquity hangs up.

Notebook Aspire5050

Adding debug info.

Dmesg output

lsusb

PD: deleting ubi-webcam.py workaround the issue well.

Guillermo - could you please open a new bug regarding your issue using the command 'ubuntu-bug ubiquity' from the live environment when the installer hangs? Please also mention this bug in your new bug. Thanks in advance!

I have runned pidgin in gdb and when placing a video call (when the other end accpeted here crashed):

@localhost:~$ gdb pidgin
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /usr/bin/pidgin...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/pidgin
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe37e7700 (LWP 2796)]
[New Thread 0x7fffe0497700 (LWP 2797)]
[New Thread 0x7fffdfc96700 (LWP 2798)]
[New Thread 0x7fffd6141700 (LWP 2832)]
[New Thread 0x7fffcb01b700 (LWP 2833)]
[New Thread 0x7fffc3fff700 (LWP 2834)]
[New Thread 0x7fffca41a700 (LWP 2835)]
[New Thread 0x7fffc9c19700 (LWP 2836)]
[New Thread 0x7fffc37fe700 (LWP 2837)]
[New Thread 0x7fffc2ffd700 (LWP 2838)]
[New Thread 0x7fffc27fc700 (LWP 2839)]
[New Thread 0x7fffc1ffb700 (LWP 2840)]
[New Thread 0x7fffc17fa700 (LWP 2841)]
[New Thread 0x7fffc0ff9700 (LWP 2842)]
[New Thread 0x7fffb7ffe700 (LWP 2843)]
[New Thread 0x7fffb6c3c700 (LWP 2844)]
[New Thread 0x7fffb643b700 (LWP 2845)]
[New Thread 0x7fffb5c3a700 (LWP 2846)]
[Thread 0x7fffc1ffb700 (LWP 2840) exited]
[New Thread 0x7fffb5227700 (LWP 2847)]
[New Thread 0x7fffb4a26700 (LWP 2848)]
[Thread 0x7fffc17fa700 (LWP 2841) exited]
[New Thread 0x7fffc17fa700 (LWP 2849)]
[New Thread 0x7fffa9e0d700 (LWP 2850)]
[New Thread 0x7fff73ba4700 (LWP 2851)]
[New Thread 0x7fffa93ff700 (LWP 2852)]
[New Thread 0x7fffa8bfe700 (LWP 2853)]
[New Thread 0x7fff733a3700 (LWP 2854)]
DtsGetHWFeatures: Create File Failed
DtsGetHWFeatures: Create File Failed
Running DIL (3.22.0) Version
DtsDeviceOpen: Opening HW in mode 0
DtsDeviceOpen: Create File Failed
[Thread 0x7fffb5227700 (LWP 2847) exited]
[Thread 0x7fffca41a700 (LWP 2835) exited]
[Thread 0x7fffc3fff700 (LWP 2834) exited]
[Thread 0x7fffcb01b700 (LWP 2833) exited]
[Thread 0x7fffb7ffe700 (LWP 2843) exited]
[Thread 0x7fffd6141700 (LWP 2832) exited]
[Thread 0x7fffc17fa700 (LWP 2849) exited]
[Thread 0x7fffc37fe700 (LWP 2837) exited]
[Thread 0x7fffb5c3a700 (LWP 2846) exited]
[Thread 0x7fffc2ffd700 (LWP 2838) exited]
[Thread 0x7fffc27fc700 (LWP 2839) exited]
[Thread 0x7fff73ba4700 (LWP 2851) exited]
[Thread 0x7fffa9e0d700 (LWP 2850) exited]
[Thread 0x7fffc9c19700 (LWP 2836) exited]
[Thread 0x7fffb4a26700 (LWP 2848) exited]
[Thread 0x7fffe0497700 (LWP 2797) exited]
[Thread 0x7fff733a3700 (LWP 2854) exited]
[Thread 0x7fffb643b700 (LWP 2845) exited]
[Thread 0x7fffc0ff9700 (LWP 2842) exited]
[Thread 0x7fffa8bfe700 (LWP 2853) exited]
[Thread 0x7fffb6c3c700 (LWP 2844) exited]
[New Thread 0x7fffb6c3c700 (LWP 2858)]

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff5012e2d in g_slice_alloc ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
(gdb...

Pedro, I'm sure you are experiencing a bug and that you want to report it so that it can be fixed. However, in order to do that, please file a new bug instead of commenting on a bug report for a bug that has already been fixed.

Just for the record: Had this problem today with the current 12.10 64-bit installer on a Lenovo E530. The installer was booted via EFI from USB stick.

Removing the ubi-webcam.py didn't work. But I noticed a "dd" process taking ~10% CPU although the installer showed that all files were already copied. A few minutes later this was still the case so I killed that process and voilà - the installer went on and finished successfully.

My installation layout:

/dev/sda (1TB HDD)
/dev/sda1 - /home (999GB)
/dev/sda2 - swap (1GB)

/dev/sdb (16GB mSATA SSD)
/dev/sdb1 - efi (256MB)
/dev/sdb2 - / (15.7GB)

Maybe it has something to do with it?

@Markus Birth, from your description it seems you have a different bug. Besides, I can confirm the bug in this report has been fixed.

If it was not an incident and you can reproduce the bug, you should try to find a bug report that is identical to yours, or else submit a new bug report.