I am now able to reproduce the crash even with older version of v8cgi, which worked flawlessly with older V8 (~ may 2010). I am slowly starting to believe that the problem might be actually caused by V8 and not by v8cgi.
Additional data for inspection: - Happens only with Windows XP/MinGW - Stacktrace in first post - Registers: eax 0xf601488c -167688052 ecx 0x1 1 edx 0x0 0 ebx 0xf841dc 16269788 esp 0x22f9c8 0x22f9c8 ebp 0x22f9e0 0x22f9e0 esi 0x20082cd 33587917 edi 0xf841dc 16269788 eip 0x63e3346a 0x63e3346a <v8::internal::HeapObject::map_word()+10> eflags 0x10282 [ SF IF RF ] cs 0x1b 27 ss 0x23 35 ds 0x23 35 es 0x23 35 fs 0x3b 59 gs 0x0 0 - Assembler dump: 0x63e33460 <+0>: push %ebp 0x63e33461 <+1>: mov %esp,%ebp 0x63e33463 <+3>: sub $0x18,%esp 0x63e33466 <+6>: mov 0x8(%ebp),%eax 0x63e33469 <+9>: dec %eax => 0x63e3346a <+10>: mov (%eax),%eax 0x63e3346c <+12>: mov %eax,0x4(%esp) 0x63e33470 <+16>: lea -0x4(%ebp),%eax 0x63e33473 <+19>: mov %eax,(%esp) 0x63e33476 <+22>: call 0x63e88d6c <v8::internal::MapWord::MapWord(uintptr_t)> 0x63e3347b <+27>: mov -0x4(%ebp),%eax 0x63e3347e <+30>: leave 0x63e3347f <+31>: ret End of assembler dump. Thanks a lot, Ondrej On Nov 26, 3:42 pm, Ondřej Žára <[email protected]> wrote: > Hi Stephan, > > thanks a lot for providing assistance. Unfortunately, both of your > ideas are not the case: > > - I never dlclose() anything, > - no C++ exception is being thrown. > > I also tried to recompile my code against an older V8 revision (May > 2010), which I used for previous release of v8cgi (without problems, > at that time). This particular crash disappeared, but other crashes > (GetInternalField) remain the same, which signals that the problem is > most probably caused by *my* recent experiments and changes regarding > DLLs, their compilation and linking with MinGW. Shit :-( > > Sincerely, > Ondrej > > 2010/11/26 Stephan Beal <[email protected]>: > > > On Fri, Nov 26, 2010 at 3:03 PM, ondras <[email protected]> wrote: > > >> * it happens only on windows (mingw); > >> * it is very difficult to isolate the problem (offending calls are > >> made from a dlopen()'ed DLL module...); > > > Out of curiosity, are you ever dlclose()ing the DLL? In general case, it is > > never safe to close a DLL, since they can allocate arbitrary resources in > > the main app which then refer to dead space when the DLL is closed. It is > > only halfway safe in very, very controlled cases. See: > >http://code.google.com/p/v8-juice/wiki/Plugins#DLLs_are_never_unloaded > > for more thoughts on that. > > >> #10 0x63c877fe in v8::internal::Invoke (construct=false, func=..., > >> receiver=..., argc=4, args=0x22fd20, > >> has_pending_exception=0x22fcbf) > >> ...#16 0x004082f2 in main (argc=2, argv=0x3e5400) at src\v8cgi.cc:254 > >> (gdb) > > > Was a _native_ exception thrown in here? If so, you might try making sure > > that the exception does not cross DLL boundaries. From what the gurus (e.g. > > Herb Sutter) say, it's not portable to allow them to cross library > > boundaries, and doing so can lead to undefined behaviour. (That said, in my > > experience it works just fine.) > > -- > > ----- stephan beal > >http://wanderinghorse.net/home/stephan/ > > > -- > > v8-users mailing list > > [email protected] > >http://groups.google.com/group/v8-users -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
