Re: 21_strings/insert.cc on the mainline

[Phil Edwards <pedwards at disaster dot jaj dot com>]

[cc'd to the gdb list in the desparate hope of help]


On Tue, Apr 17, 2001 at 01:49:42AM +0200, Peter Schmid wrote:
> I cannot
> tell what happens exactly since gdb is doing strange things,

That's the understatement of the year.  :-(

I hypothesized that using "-ggdb3" may have been tickling some bugs.  So I
compiled the library with -O0 -g and the test executable with the same.
The behavior of gdb was still odd, but consistent.

Given

 *  statement 1   [generating actual assembly code]
    statement 2
    statement 3
    try {
 *      statement 4   [should throw something]
    }
    catch (...) {
        statement 5
    }
    statement 6
    statement 7
    statement 8
 *  statement 9

with * indicating a breakpoint set, I've found that using 'n'ext will
correctly move through statements 1 through 4, i.e., 'n' has been pressed 3
times and I am about to execute statement 4.  Pressing 'n' will then skip
to statement 9.  Pressing 'n' after that point will likewise only stop at
breakpoints, not statements.

Something in the unwinding?  I dunno.  Happens each run, though.

I tried to inspect some of the string objects after the 4->9 jump to see
if the same corruption[*] had occurred, but "p str02.c_str()" caused a SEGV
accompanied by a message like, "this program died after receiving a signal
caused by a function that gdb itself called, boy that's gotta hurt," but
I don't know whether that's indicative of corruption or just gdb being weird.

Unless somebody can come up with some inspiration, I think I'm giving up
on 21_strings/insert.cc for the time being.  The tools are less predictable
than the test.


Phil
[*] Same as that which I reported previously, I mean.

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.