Bug 538626 - gdb crashes when trying to condition a breakpoint on the results of a function call
Summary: gdb crashes when trying to condition a breakpoint on the results of a functio...
Alias: None
Product: Fedora
Classification: Fedora
Component: gdb
Version: 12
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Phil Muldoon
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2009-11-18 23:32 UTC by Boris Zbarsky
Modified: 2009-12-14 20:15 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-12-14 20:15:35 UTC

Attachments (Terms of Use)
Stack trace (bt full) to the crash (6.56 KB, text/plain)
2009-11-18 23:32 UTC, Boris Zbarsky
no flags Details
Patch to copy location list array (4.99 KB, patch)
2009-11-24 14:51 UTC, Phil Muldoon
no flags Details | Diff

Description Boris Zbarsky 2009-11-18 23:32:56 UTC
Created attachment 370225 [details]
Stack trace (bt full) to the crash

Description of problem:
gdb crashes when trying to have a conditional breakpoint that calls a function

Version-Release number of selected component (if applicable):

How reproducible: Reproducible

Steps to Reproduce:
1. Install the x86_64 distribution of FC12
2. hg clone http://hg.mozilla.org/mozilla-central/
3. hg up -C -r b55fcd30070a
4. Create a .mozconfig that has these options:

    ac_add_options --enable-debug
    ac_add_options --disable-optimize
    ac_add_options --enable-extensions=default,layout-debug
    ac_add_options --enable-application=browser

   and compile.
5. Run "firefox -g" from the resulting dist/bin
6. At the prompt, type "run" and wait for the browser to start
7. Start loading http://pastie.org/705016 in the browser
8. Hit Ctrl-c in gdb (needs to happen pretty quickly after step 7)
9. Type 

  break 'nsCSSFrameConstructor::PostRestyleEvent(nsIContent*, nsReStyleHint,

    in gdb.
10. Type "cont" in gdb.
11. When the breakpoint set in step 9 is hit, type
    "condition 1 (aContent->IsXUL() == 0)" in gdb.  At least if the breakpoint
    ended up numbered 1 and not 0.
12. Type "cont" in gdb.
Actual results: gdb crashes

Expected results: Not crash.

Additional info: I attached gdb to gdb before step 12 above and get:

Program received signal SIGSEGV, Segmentation fault.
bpstat_stop_status (bp_addr=140737073962093, ptid=...)
    at ../../gdb/breakpoint.c:3330
3330        b = bl->owner;
(gdb) p bl
$1 = (struct bp_location *) 0xff0

Full stack trace attached.

I can reproduce this at will, so if you need any other information that I can get you, please just ask.

Comment 1 Phil Muldoon 2009-11-19 15:56:18 UTC
I believe this is also a reproducer:

int i = 0;

int whatisi()
  return i;

main () 
  int l = 0;
  for (l = 0; l < 100; l++)

Compile it with

gcc -O0 -g3 main.c -o main

Start gdb with it and place the breakpoint like so

gdb main
b 13 if (whatisi() == 50)

then run, and you will have a crash as reported above. Running GDB
under GDB also see:

Program received signal SIGSEGV, Segmentation fault.
0x00000000004eaf2f in bpstat_stop_status (aspace=Reading in symbols for ../../src/gdb/progspace.c...done.
0xc0ebf0, bp_addr=4195476, ptid=...) at ../../src/gdb/breakpoint.c:3449
3449	    b = bl->owner;

Both conditions make inferior function calls in the condition
statement, so it might indicate an issue there. 

(As a side-note are conditions evaluated at each stop, or is the
condition parsed only when the breakpoint is set?)

Comment 2 Phil Muldoon 2009-11-19 16:10:53 UTC
The only box I had handy locally was a Fedora 10 box with:

GNU gdb Fedora (6.8-29.fc10)

And resolution of that condition does work there:

(gdb) b 13 if (whatisi() == 50)
Breakpoint 1 at 0x80483bf: file simple.c, line 13.
(gdb) r
Starting program: /build/simple 

Breakpoint 1, main () at simple.c:13
13	      i++; 
(gdb) p i
$1 = 50

I don't have a F11 box around, but it looks like a GDB 7 regression

Comment 3 Jan Kratochvil 2009-11-19 16:15:21 UTC
(In reply to comment #1)
> (As a side-note are conditions evaluated at each stop, or is the
> condition parsed only when the breakpoint is set?)  

`char *' (breakpoint->cond_string) is parsed into `struct expression *'
(bp_location->cond) in general only when creating the breakpoint.  But in some
situations it gets reparsed.

Comment 4 Phil Muldoon 2009-11-24 07:24:40 UTC
This is the result of an inferior function call in a breakpoint condition causing a rebuild of the bp_location array whilst in a loop. The loop (ALL_BP_LOCATIONS) inside of the function bpstat_stop_status is not change safe. As in this testcase, the condition causes an inferior function call to be made. Part of the construction of an inferior function call requires the insertion of momentary breakpoints into  the dummy frame (to catch function exit). This is later deleted, and this causes the bp_location array to be rebuilt.  This corrupts the bp_location index in the current loop, that later leads to a sigsegv in

Comment 5 Phil Muldoon 2009-11-24 14:51:49 UTC
Created attachment 373452 [details]
Patch to copy location list array

Possible fix. Copy the array temporarily to isolate it from inferior function call breakpoint clean-up trigger of update_global_locations.

Comment 6 Fedora Update System 2009-11-25 10:53:34 UTC
gdb-7.0-7.fc12 has been submitted as an update for Fedora 12.

Comment 7 Fedora Update System 2009-11-27 21:59:10 UTC
gdb-7.0-7.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 8 Boris Zbarsky 2009-11-28 05:37:12 UTC
Just confirmed that gdb-7.0.7.fc12 fixes the issue I was seeing.  Phil, thank you very much for fixing this!

Note You need to log in before you can comment on or make changes to this bug.