Bwahah. It's obvious, now. The argument variable was pointing to a location on the stack, so when the function was called, it put its own local variables on the stack, overwriting the memory at the location argument was pointing to. That also explains why the behavoir of the bug changed with -O because optimization may have inlined a function or changed the stack allocation behavior-stuff.
It would be interesting to see what "print argument" would have shown immediately before the call to one_arg, because I think argument would have already been corrupted then by the initialization of arg (which is initialized with random crap because it's unassigned, which initialization would be eliminated by -O). I knew something was suspicious when ch was a pointer to memory at 0x4032... and argument was 0xbfff.... Since arg is also an 0xbfff address, it obvious that argument is pointing to the stack. I bet that now that you've fixed the code, if you go with gdb into do_set like before, argument's address will be close to ch's. It looks like you may have a memory leak though, unless there's a provision somewhere for freeing those str_dup'ed returned strings. -David > ----- Original Message ----- > From: "Richard Lindsey" <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Wednesday, July 21, 2004 1:21 PM > Subject: More corruption... > > A while back, I sent a mail out to the list about my rgObjNest being > corrupted, and I ended up just manually deleting the pfile in question... > I've had a couple of other quirks pop up, such as in pload, a command that > was working fine one day and not the next, it appeared that the argument was > getting trashed when sent to the one_argument function, and it would lead to > a crash... well through some experimentation, and I'm not quite sure why > this worked, but I discovered that if I removed the optimization flag (-O) > from the Makefile, this problem ceased; putting that flag back in place > caused the problem to pop up again... no biggie, sometimes I don't like > optimization in place anyway when I'm trying to debug loops... anyway, now > that optimization *isn't* in place, the problem seems to have crept into > another function (and who knows how many it's affecting that I just haven't > discovered yet)... upon trying to set a stat on myself, it kept popping up > the syntax, so when I typed 'set char' by itself, to echo the syntax of > those fields... *crash*... when I run it in gdb and break at do_set and step > through the first statement, this is the output: > > Breakpoint 1, do_set (ch=0x4032f388, argument=0xbfff8dd0 "char") at > act_wiz.c:4131 > 4131 argument = one_argument(argument,arg); > (gdb) step > one_argument (argument=0xbfff8dd0 "Ð\215ÿ¿à\215ÿ¿", arg_first=0xbfff8de0 "") > at interp.c:943 > 943 char cEnd; > > as you can see, where it breaks at the beginning of do_set, > argument=0xbfff8dd0 "char", so that data is intact... the first step tho, > into one_argument, trashes the argument, and from there it tries to process > that and crashes... this is the same exact thing that was happening to pload > with the -O flag in place for gcc... now that I've removed that flag, it > doesn't affect pload anymore, but now it seems to be affecting do_set... any > ideas what's going on here? This is also on a different server than the > problem had originally popped up on, and yet it's recreatable on either one; > at first I'd suspected corrupted memory modules or something, but on 2 > different machines I wouldn't expect that to be the case... help! :) > > Richard Lindsey.
