Closed Bug 314247 Opened 20 years ago Closed 7 years ago

cannot run under gdb with "-g"

Categories

(Toolkit :: Startup and Profile System, defect)

Product:
Toolkit
Component:
Startup and Profile System
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: calum.mackay, Unassigned, NeedInfo)

Details

User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7.10) Gecko/20050726 Firefox/1.0.6 Build Identifier: I find I'm no longer able to run an app under gdb using "-g". I found this using sunbird, but a friend has reproduced under seamonkey on a different system. We believe this was working a week or two ago. # it all starts up fine... /usr/local/src/mozilla/sunbird/sunbird-200510281725/sunbird -splash -g /usr/local/src/mozilla/sunbird/sunbird-200510281725/run-mozilla.sh -g /usr/local/src/mozilla/sunbird/sunbird-200510281725/sunbird-bin -splash moz_debug=1 moz_debugger= /usr/bin/ddd --debugger "gdb -x /tmp/mozargs.Brnf3L" /usr/local/src/mozilla/sunbird/sunbird-200510281725/sunbird-bin GNU DDD 3.3.11 (i486-pc-linux-gnu), by Dorothea Lütkehaus and Andreas Zeller. Copyright © 1995-1999 Technische Universität Braunschweig, Germany. Copyright © 1999-2001 Universität Passau, Germany. Copyright © 2001 Universität des Saarlandes, Germany. Copyright © 2001-2004 Free Software Foundation, Inc. Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) show version GNU gdb 6.3-debian # but trying to start the app fails (gdb) run [Thread debugging using libthread_db enabled] [New Thread -1219016480 (LWP 32271)] (sunbird-bin:32271): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. [New Thread -1238365264 (LWP 32276)] [New Thread -1246757968 (LWP 32277)] calItemModule: registering @mozilla.org/calendar/manager;1 calItemModule: registering @mozilla.org/calendar/alarm-service;1 registering for category stuff calItemModule: registering @mozilla.org/calendar/event;1 calItemModule: registering @mozilla.org/calendar/todo;1 calItemModule: registering @mozilla.org/calendar/attendee;1 calItemModule: registering @mozilla.org/calendar/attachment;1 calItemModule: registering @mozilla.org/calendar/recurrence-info;1 calItemModule: registering @mozilla.org/calendar/import;1?type=ics registering for category stuff calItemModule: registering @mozilla.org/calendar/export;1?type=ics registering for category stuff calItemModule: registering @mozilla.org/calendar/export;1?type=html registering for category stuff calItemModule: registering @mozilla.org/calendar/import;1?type=csv registering for category stuff calItemModule: registering @mozilla.org/calendar/export;1?type=csv registering for category stuff Starting calendar alarm service observer added [New Thread -1255576656 (LWP 32278)] [Thread -1238365264 (LWP 32276) exited] [Thread -1255576656 (LWP 32278) exited] observer removed [Thread -1246757968 (LWP 32277) exited] Cannot find user-level thread for LWP 32271: generic error (gdb) Reproducible: Always Steps to Reproduce: 1.run app with "-g" 2. 3. Actual Results: failure as shown Expected Results: should run under gdb
> Cannot find user-level thread for LWP 32271: generic error isn't that a gdb issue rather than a mozilla one?
Quite probably, but I've logged it here for two reasons: o It was apparently working until very recently o Since moz apps directly control gdb startup, via the "-g", it seems reasonable to note here that this is no longer working, even if it's just a placeholder bug for others to see. If the decision is that this is definitely a gdb bug, then please feel free to close.
Confirmed that it's failing for me too on Linux with seamonkey cvs. Even cd'ing to the directory, setting LD_LIBRARY_PATH and gdb'ing seamonkey-bin fails. However i must also add that i 'upgraded' to gdb 6.3 very recently also. Will try an earlier version - 6.2.1 next home /usr/local/mozilla% LD_LIBRARY_PATH=`pwd` gdb seamonkey-bin GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"...(no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (gdb) r Starting program: /usr/local/mozilla/seamonkey-bin warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. warning: shared library handler failed to enable breakpoint Program received signal SIG32, Real-time event 32. 0xb740e301 in ?? () (gdb)
Confirmed that this is a gdb bug. I downgraded to 6.2.1 and it works perfect. Calum, suggest logging bug with Debian. Ok to close. home /usr/local/mozilla% !LD LD_LIBRARY_PATH=`pwd` gdb seamonkey-bin GNU gdb 6.2.1 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"...(no debugging symbols found)...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) r Starting program: /usr/local/mozilla/seamonkey-bin (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 15927)] [New Thread 32769 (LWP 15934)] [New Thread 16386 (LWP 15935)] [New Thread 32771 (LWP 15936)] [New Thread 49156 (LWP 15937)] [New Thread 65541 (LWP 15938)] [New Thread 81926 (LWP 15939)] [New Thread 98311 (LWP 15940)] [Thread 81926 (LWP 15939) exited] [Thread 49156 (LWP 15937) exited] [Thread 65541 (LWP 15938) exited] [Thread 98311 (LWP 15940) exited] [Thread 16386 (LWP 15935) exited] [Thread 32771 (LWP 15936) exited] Program exited with code 01.
thanks Mitch.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
re-opening, which I hope is ok. I logged a gdb bug, via Debian, which can be seen here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=341617 which was resolved as not going to be fixed; in summary: "GDB doesn't support debugging across execve()" and it may be that mozilla is relying on this support?
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
can you be clear what this bug is about? this bug currently contains at least two issues (that SIG32 thing, and the application restart thing) you may want to set NO_EM_RESTART=1 when debugging.
I think Mitch's comments may be a separate issue; the issue in this bug is the "generic error" since gdb does not doesn't support debugging across execve(). thanks; will try that env var.
the env var is for that execve thing I still believe that the the generic error is a gdb bug and unrelated to mozilla...
> the env var is for that execve thing am not sure what this means; there is only one issue in this bug, I think, once we discount Mitch's SIG32. The GDB folks seem to be saying that the generic error is caused by tracing across execve(), which isn't supported. Are you saying that it's a gdb bug that it's not supported? If NO_EM_RESTART=1 is needed to workaround this, would be be useful to add it to the startup script's "-g" action?
hm? as best as I could tell from the debian bug it was closed with a reference to a different issue, and that different issue could be worked around with NO_EM_RESTART. although I may be wrong. anyway, I can't figure out why it can possibly be a mozilla bug when gdb can't handle it.
(I say this because I saw comment 0's error with seamonkey, which doesn't restart itself (using execve))
right, I see now, sorry. I would note that the friend who reproduced it on seamonkey was Mitch, and it now seems that his issue (comment 3, SIG32) was actually different, and is a gdb issue. I've only reproduced this generic error problem on firefox. I'll do some more testing, and see if the env var reliably cures it; if so, perhaps we might consider adding it to the startup script. thanks much.
Unfortunately, that env var hasn't helped: diz $ env | grep NO_EM_RESTART NO_EM_RESTART=1 (gdb) run [Thread debugging using libthread_db enabled] [New Thread -1220376352 (LWP 20557)] (firefox-bin:20557): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. [New Thread -1242330192 (LWP 20562)] [New Thread -1250722896 (LWP 20563)] [New Thread -1259541584 (LWP 20564)] [New Thread -1267934288 (LWP 20565)] [New Thread -1276326992 (LWP 20566)] [New Thread -1284719696 (LWP 20567)] [New Thread -1293591632 (LWP 20569)] [New Thread -1301984336 (LWP 20570)] [Thread -1293591632 (LWP 20569) exited] thread_db_get_info: cannot get thread info: generic error This was at Firefox startup, just after it had brought up the Privacy settings dialog, and immediately after I clicked OK on that. Build done from a cvs checkout this morning, with: ac_add_options --disable-debug ac_add_options --enable-optimize="-O -g" (which is my usual setting for getting stack traces etc). various versions: ||/ Name Version Description +++-==============-==============-============================================ ii ddd 3.3.11-1 The Data Display Debugger, a graphical debug ii gdb 6.3.90.2005111 The GNU Debugger ii libc6 2.3.5-8.1 GNU C Library: Shared libraries and Timezone ii libc6-i686 2.3.5-8.1 GNU C Library: Shared libraries [i686 optimi diz $ uname -a Linux diz 2.6.14 #33 PREEMPT Sat Nov 12 21:16:39 GMT 2005 i686 GNU/Linux I'm struggling to think of what to try next. I'm keen to try and sort this out though, so if anyone has any suggestions...? One thing I can take back to the gdb folks: are we saying that if NO_EM_RESTART is set then firefox won't use execve? If so, then the reason for closing my gdb bug doesn't apply (gdb doesn't support debugging across execve) and so I can ask them to have another look.
> are we saying that if NO_EM_RESTART is set then firefox won't use execve? yeah, that sounds right. you could set a breakpoint in execve and verify that it's not hit.
FWIW, I recently had this problem too. I found that it was caused by the profile manager window - after I checked "Don't ask at startup" I could debug (Firefox) without problems...
The profile manager window still causes this problem as of the Jan 16 build of 3.0b3pre
Component: Cmd-line Features → Startup and Profile System
Product: Core → Toolkit
QA Contact: startup
Status: REOPENED → NEW
Status: NEW → UNCONFIRMED
Calum, do you still see this issue?
Flags: needinfo?(calum.mackay)
(In reply to Wayne Mery (:wsmwk, NI for questions) from comment #18) > Calum, do you still see this issue? I'm no longer sitting at/near a Linux box, sadly, so am not in a position to easily reproduce. Mitch?
Flags: needinfo?(calum.mackay) → needinfo?(Mitch)
I'm no longer building from source, but as per my previous comment, this is WFM.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago → 7 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.