2011/10/20 xunxun <xunxun1...@gmail.com>: > Hi, all > > I think this issue causes the gdb crash on XP. > You can see the thread: http://sourceware.org/ml/gdb/2011-10/msg00056.html > > My many friends and I can reproduce this crash issue, but no problem on Win7. > > On Thu, Oct 20, 2011 at 5:05 AM, Bob Breuer <breu...@mc.net> wrote: >> Kai Tietz wrote: >>> 2011/10/18 Bob Breuer <breu...@mc.net>: >>>> Kai Tietz wrote: >>>>> 2011/10/17 Bob Breuer <breu...@mc.net>: >>>>>> Richard Henderson wrote: >>>>>>> On 10/17/2011 07:09 AM, Bob Breuer wrote: >>>>>>>> Google finds a mention of longjmp failing with -fomit-frame-pointer: >>>>>>>> http://lua-users.org/lists/lua-l/2005-02/msg00158.html >>>>>>>> >>>>>>>> Looks like gcc 4.6 turns on -fomit-frame-pointer by default. >>>>>>> Hmm. This is the first I've heard of a longjmp implementation >>>>>>> failing without a frame pointer. Presumably this is with the >>>>>>> mingw i.e. msvc libc? >>>>>> Yeah, mingw from www.mingw.org which I believe uses msvcrt.dll, package >>>>>> gcc-core-4.6.1-2-mingw32-bin. >>>>>> >>>>>>> This is something that could be worked around in gcc, I suppose. >>>>>>> We recognize longjmp for some things, we could force the use of >>>>>>> a frame pointer for msvc targets too. >>>>>>> >>>>>>> For now it might be best to simply force -fno-omit-frame-pointer >>>>>>> for mingw host in the configure script. >>>>>> Here's a testcase that crashes on the longjmp: >>>>>> >>>>>> #include <stdio.h> >>>>>> #include <setjmp.h> >>>>>> >>>>>> jmp_buf env; >>>>>> >>>>>> int test(void) >>>>>> { >>>>>> int i; >>>>>> >>>>>> asm("xor %%ebp,%%ebp" ::: "ebp"); >>>>>> >>>>>> i = setjmp(env); >>>>>> printf("i = %d\n", i); >>>>>> >>>>>> if (i == 0) >>>>>> longjmp(env, 2); >>>>>> >>>>>> return i; >>>>>> } >>>>>> >>>>>> int main(void) >>>>>> { >>>>>> return test(); >>>>>> } >>>>>> >>>>>> Remove the asm statement to make it not crash. Obviously with >>>>>> omit-frame-pointer, gcc can shove anything into ebp. >>>>>> >>>>>> Bob >>>>> This crash isn'r related to ebp existing, or not. The issue is the >>>>> hidden argument of setjmp, which is missing. If you can try the >>>>> following at top of file after include section. >>>>> >>>>> #define setjmp(BUF) _setjmpex((BUF), NULL) >>>>> int __cdecl __attribute__ ((__nothrow__,__returns_twice__)) >>>>> _setjmp3(jmp_buf _Buf, void *_Ctx); >>>>> ... >>>> Did you mean _setjmp3 instead of _setjmpex? With _setjmp3, it works >>>> without the asm, but still crashes if I zero out ebp before the setjmp. >>>> Aren't the function arguments on the stack anyway? >>> >>> Yes, I mean _setjmp3 (pasto from headers and missed the second line >>> prototyping _setjmp3). >>> I repeat myself here. setjmp() has an hidden arguement, which is >>> passed on x86 on stack. By not passing this required argument, setjmp >>> will take a random-value from stack. In your case 'i'. btw if you >>> would pre-initialize 'i' with zero, I would assume you won't see a >>> crash, but anyway this is just by chance. >>> For this I suggest to use here _setjmp3 instead, as here >>> second-argument is documented as being present. >>> >>> Btw I tested your code with i686-pc-mingw32 version 4.6.x and 4.7.x >>> gcc version. With my suggested pattern, I don't see a crash for your >>> provide test-code with, or without zero-ing ebp. >> >> >> We probably have a difference in build or run environment. I've >> double-checked with another machine and can get the same crash in >> longjmp when running the test executable on both WinXP and Win2k, but >> not on Win7. So it looks like Microsoft may have changed this "feature" >> somewhere between WinXP and Win7. >> >> The msvcrt implementation of longjmp (or at least the one I'm looking >> at) does a ebp based access using the saved value of ebp. Here's the >> relevant disassembly of longjmp: >> >> 0x7801e6f3 in longjmpex () from C:\WINNT\system32\msvcrt.dll >> (gdb) disas >> Dump of assembler code for function longjmpex: >> 0x7801e6ef <+0>: mov 0x4(%esp),%ebx >> => 0x7801e6f3 <+4>: mov (%ebx),%ebp >> ... >> 0x7801e73d <+78>: call 0x7800bd5e <abnormal_termination+56> >> ... >> 0x7800bd5e <+56>: push %ebx >> 0x7800bd5f <+57>: push %ecx >> 0x7800bd60 <+58>: mov $0x7803dc64,%ebx >> => 0x7800bd65 <+63>: mov 0x8(%ebp),%ecx >> >> It crashes on the access of 0x8(%ebp). Those are the only 2 places >> where this version of longjmp touches ebp. Is it possible to force a >> stackframe by just adding a suitable attribute to either the setjmp >> function prototype, or the function which calls setjmp? >> >> Bob >> > > > > -- > Best Regards, > xunxun
This now makes sense. I use here Vista 64-bit, and Win7 64-bit and I didn't found the issue. But well, it is indeed related to different msvcrt-version. So there might be some need to have for a function using setjmp the frame-pointer enabled. I can confirm this by an older msvcrt.dll version on my 64-bit box, too. So bug can be re-opened. Thanks, Kai
