GNOME Bugzilla – Bug 150239
Gnopernicus crashes gnome-terminal
Last modified: 2004-12-22 21:47:04 UTC
Using Gnopernicus 0.9.8 and gnome-terminal 2.6.1. If you type ls -lrtFa. Gnome-terminal will crash. The following is the result of a pstack on the core file core 'core' of 7247: /usr/bin/gnome-terminal ----------------- lwp# 1 / thread# 1 -------------------- d1782574 memcpy (8141f98, 80ba10c, 80ba120, 80ba134, 5b8, 338001) + 14 ----------------- lwp# 2 / thread# 2 -------------------- d1801c5c _read (1c, d017df98, 14) + c d1884710 child_watch_helper_thread (d12e8400) + 1e d1800cb0 _lwp_start (d12e8400, 0, 0, d18df78c, 0, 1) If gnopernicus is not running ls -lrtFa doesn't crash gnome-terminal
check bug 141194 to see if this might be a dup...
I am not able to reproduce this bug on Linux, using Gnopernicus 0.9.8 and gnome-terminal 2.6.1. Both applications (gnopernicus and gnome-terminal) keep running after 'ls -lrtFa'. (Why the summary of this bug is 'Gnopernicus crashes braille monitor'? I believe it should be something like 'Gnopernicus crashes gnome-terminal'...)
Anyway, I believe this is not a gnopernicus bug. The problem is in gnome-terminal.
I agree that this is most likely a gnome-terminal bug. I will investigate.
After further testing I have found that you have to have braille monitor running to recreate this bug.
How are you starting gnopernicus? Is it started in background (gnopernicus &) in _same_ _gnome-terminal_ (where you launched ls -lrtFa)? This may be relevant in this case. Please try to run gnopernicus with output redirected to a file (gnopernicus 2>log). Also try to start gnopernicus from a xterm. Is bug present in these cases? Gnopernicus sends datas to braille monitor in a XML format using an udp connection. For such kind of conection, packages may be lost. In this case, the SAX parser will emmit same warning messages . ls -al... is a command which generates a lot of output. If a package is lost then a warning will be displayed. This will generate some events which will be also reported by gnopernicus. Again, warning messages may be generated byy parser, and those will be also reported, and so on. So, I suspect a "avalanche" of events, an event will generate output, the output will generate other events, and so on. This is _not_ gnopernicus bug. The crash is another process. Transfering to gnome-terminal.
It doesn't matter how I start gnopernicus the crash always occurs. Although if you run gnopernicus from a gnome-terminal using gnopernicus & and run ls -lrtFa from the same gnome-terminal you have to run the command again to get gnome-terminal to crash. If I run gnopernicus with the output directed to a log file (using gnopernicus>log) the crash still occurs and it generates an empty log file. If I run xterm from a gnome-terminal (using xterm &) and launch gnopernicus from the xterm using (gnopernicus &) and run ls-lrtFa from the xterm the crash will not occur. However if I run ls -lrtFa from the same gnome-terminal that I lauched the xterm from gnome-terminal will crash. If I use a new gnome-terminal window to run ls -lrtFa sometimes gnome-terminal will crash.
David has reproduced this on Solaris x86. I have tried to reproduce it on Solaris sparc but have not seen a crash. I have seen the following warning messages from brlmonitor: (brlmonitor:4420): gnopernicus-CRITICAL **: file brlmonui.c: line 796: assertion `pos >= FIRST_POSITION && pos < panel_size' failed (brlmonitor:4420): gnopernicus-CRITICAL **: file brlmonui.c: line 796: assertion `pos >= FIRST_POSITION && pos < panel_size' failed (brlmonitor:4420): gnopernicus-CRITICAL **: file brlmonui.c: line 796: assertion `pos >= FIRST_POSITION && pos < panel_size' failed (brlmonitor:4420): gnopernicus-CRITICAL **: file brlmonui.c: line 796: assertion `pos >= FIRST_POSITION && pos < panel_size' failed (brlmonitor:4420): gnopernicus-CRITICAL **: file brlmonui.c: line 796: assertion `pos >= FIRST_POSITION && pos < panel_size' failed (brlmonitor:4420): gnopernicus-CRITICAL **: file brlmonui.c: line 796: assertion `pos >= FIRST_POSITION && pos < panel_size' failed (brlmonitor:4420): gnopernicus-CRITICAL **: file brlmonui.c: line 796: assertion `pos >= FIRST_POSITION && pos < panel_size' failed
From Padraig comment, in some cases gnopernicus generates an output. The output generates events. Gnopernicus reacts to them, and generates other output. This is the main cause of this bug.
Is this really worthy of Priority: Immediate?
not based on comment #5.
Stack trace shows that this can be a duplicate of bug#153405. Padraig just gave a patch to the other bug.
*** This bug has been marked as a duplicate of 153405 ***