in reply to Re^3: Event module and threads/fork segfault on Win32
in thread Event module and threads/fork segfault on Win32

This is interesting... I'm running newer versions of everything...
C:\>perl -v This is perl, v5.8.8 built for MSWin32-x86-multi-thread (with 50 registered patches, see perl -V for more detail) Copyright 1987-2006, Larry Wall Binary build 820 [274739] provided by ActiveState http://www.ActiveSta +te.com Built Jan 23 2007 15:57:46 Perl may be copied only under the terms of either the Artistic License + or the GNU General Public License, which may be found in the Perl 5 source ki +t. Complete documentation for Perl, including FAQ lists, should be found +on this system using "man perl" or "perldoc perl". If you have access to + the Internet, point your browser at http://www.perl.org/, the Perl Home Pa +ge. C:\>perl -MEvent -e"print qq($Event::VERSION\n)" 1.08 C:\>perl -Mthreads -e"print qq($threads::VERSION\n)" 1.58
The OS is WinXP Professional SP2 running in a VMWare VM v5.5.51 build-19175

The real code starts threads in one watcher and joins them in another to collect their exit statuses. In that situation it gets the "leaked scalar" before the segfault.

Replies are listed 'Best First'.
Re^5: Event module and threads/fork segfault on Win32
by BrowserUk (Patriarch) on Jun 05, 2007 at 16:04 UTC

    To resolve this you're probably going to have to track down which version of what caused things to break and then raise a specific bug report against the specific component. And that will likely be a PITA, as there are so many versions and combinations of versions to test. For example; threads appears to have gone through around 20+ version between where you are and I am.

    A few things that might help:

    • I downloaded the latest version (v109) of Event that was available from CPAN. I'm not sure how/where you obtained a later version?

      It's also worth poiting out that the POD carries the following warnings:

      The scope of events is pretty strange compared to most other perl objects. I'm not sure if this is a bug or a feature (OK, probably it was a mistake). ...

      There seems to be some sort of bug in the global destruction phase:

      Attempt to free unreferenced scalar during global destruction. Use of uninitialized value during global destruction. Explicit blessing to '' (assuming package main) during global destruction.

      The latter may be, (is probably), the source of the "1 leaked scalar" message issued. Although this message is associated with threads, it may well be that it is simply that it bothers to check.

      Ie. The scalar could be leaked whenever you use Event, but is only detected and reported when you use Event in conjunction with threads.

      The former may mean that the two modules may never properly coexist?

    • You might be able to verify the source of the problem as being in the eevent module, by using them together within the same program, but but keeping their respective code separate.

      Ie. Start and join a thread from the main thread, but do not use Event within that thread. Then create an Event timer callback, that does nothing with threads; run the dispatch loop and allow the program to terminate. If you still see one or the other of the symptoms, it will indicate...something :)

    • I've downloaded, but haven't yet installed the latest CPAN version of threads.

      I'm a litte reluctant to risk screwing my main installation of Perl, but I may try backing up my libraries for quick reversion, and installing it later tonight.

    HTH some. Good luck.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
Re^5: Event module and threads/fork segfault on Win32
by BrowserUk (Patriarch) on Jun 06, 2007 at 03:12 UTC

    It would appear to be 5.8.8 that is the deciding factor as to whether it segfaults or not. Having installed the latest versions threads:v1.62 and Event:v1.09; I get no trap from your code under 5.8.6(AS811), but I do under 5.8.8(AS817).

    However, if I do not nest the threads stuff inside the Event callback, no trap occurs either. HTH.


    Update: I finally got the segfault to occur under the auspices of a debugger.

    The trap is occurring in ev.c:187, when the if statement attempts to access WvACTIVE(wa). That doesn't explain why it happens, but it might give somebody a starting point.

    Disassembly of Function Event.dll!pe_event_postCB (0x00363D57) ;******************************************************************* +************* SYM:pe_event_postCB <Void> ; ev.c - Line 183 ; static void pe_event_postCB(pe_cbframe *fp) { 0x363D57: PUSH EBP 0x363D58: MOV EBP,ESP 0x363D5A: SUB ESP,0xC ; ev.c - Line 184 ; pe_event *ev = fp->ev; 0x363D5D: MOV EAX,DWORD PTR [EBP+0x8] ; ARG:fp <pe +_cbframe *> 0x363D60: MOV EAX,DWORD PTR [EAX] 0x363D62: MOV DWORD PTR [EBP-0x4],EAX ; VAR:ev <pe +_event *> ; ev.c - Line 185 ; pe_watcher *wa = ev->up; 0x363D65: MOV EAX,DWORD PTR [EBP-0x4] ; VAR:ev <pe +_event *> 0x363D68: MOV EAX,DWORD PTR [EAX+0x8] 0x363D6B: MOV DWORD PTR [EBP-0x8],EAX ; VAR:wa <pe +_watcher *> ; ev.c - Line 186 ; --CurCBFrame; 0x363D6E: MOV EAX,DWORD PTR [0x10012020] 0x363D73: DEC EAX 0x363D74: MOV DWORD PTR [0x10012020],EAX ; ev.c - Line 187 ; if (WaACTIVE(wa) && WaINVOKE1(wa) && WaREPEAT(wa)) 0x363D79: MOV EAX,DWORD PTR [EBP-0x8] ; VAR:wa <pe +_watcher *> + 0x363D7C: MOV EAX,DWORD PTR [EAX+0x20] ; TRAP OCCUR +S HERE <<<<<<<<<<<<<<<<< 0x363D7F: AND EAX,0x1 0x363D82: TEST EAX,EAX 0x363D84: JZ 0x363DB0 ; (*+0x2C) 0x363D86: MOV EAX,DWORD PTR [EBP-0x8] ; VAR:wa <pe +_watcher *> 0x363D89: MOV EAX,DWORD PTR [EAX+0x20] 0x363D8C: AND EAX,0x4000 0x363D91: TEST EAX,EAX 0x363D93: JZ 0x363DB0 ; (*+0x1D) 0x363D95: MOV EAX,DWORD PTR [EBP-0x8] ; VAR:wa <pe +_watcher *> 0x363D98: MOV EAX,DWORD PTR [EAX+0x20] 0x363D9B: AND EAX,0x2000 0x363DA0: TEST EAX,EAX 0x363DA2: JZ 0x363DB0 ; (*+0xE) ; ev.c - Line 188 ; pe_watcher_on(wa, 1); 0x363DA4: PUSH 0x1 0x363DA6: PUSH DWORD PTR [EBP-0x8] ; VAR:wa <pe +_watcher *> 0x363DA9: CALL 0x3642EA ; SYM:pe_wat +cher_on <Char *> 0x363DAE: POP ECX 0x363DAF: POP ECX ; ev.c - Line 189 ; if (Estat.on) { 0x363DB0: CMP DWORD PTR [0x10014268],0x0 ; <==0x00363 +DA2(*-0xE), 0x00363D93(*-0x1D), 0x00363D84(*-0x2C) 0x363DB7: JZ 0x363E2C ; (*+0x75) ; ev.c - Line 190 ; if (fp->stats) { 0x363DB9: MOV EAX,DWORD PTR [EBP+0x8] ; ARG:fp <pe +_cbframe *> 0x363DBC: CMP DWORD PTR [EAX+0x8],0x0 0x363DC0: JZ 0x363DDA ; (*+0x1A) ; ev.c - Line 191 ; Estat.scrub(fp->stats, wa); 0x363DC2: PUSH DWORD PTR [EBP-0x8] ; VAR:wa <pe +_watcher *> 0x363DC5: MOV EAX,DWORD PTR [EBP+0x8] ; ARG:fp <pe +_cbframe *> 0x363DC8: PUSH DWORD PTR [EAX+0x8] 0x363DCB: CALL DWORD PTR [0x1001427C] 0x363DD1: POP ECX 0x363DD2: POP ECX ; ev.c - Line 192 ; fp->stats = 0; 0x363DD3: MOV EAX,DWORD PTR [EBP+0x8] ; ARG:fp <pe +_cbframe *> 0x363DD6: AND DWORD PTR [EAX+0x8],0x0 ; ev.c - Line 194 ; } ; if (CurCBFrame >= 0) { 0x363DDA: CMP DWORD PTR [0x10012020],0x0 ; <==0x00363 +DC0(*-0x1A) 0x363DE1: JL 0x363E2C ; (*+0x4B) ; ev.c - Line 195 ; pe_cbframe *pfp = CBFrame + CurCBFrame; 0x363DE3: MOV EAX,DWORD PTR [0x10012020] 0x363DE8: IMUL EAX,EAX,0xC 0x363DEB: ADD EAX,0x10014438 0x363DF0: MOV DWORD PTR [EBP-0xC],EAX ; VAR:pfp <p +e_cbframe *> ; ev.c - Line 196 ; if (!pfp->stats) 0x363DF3: MOV EAX,DWORD PTR [EBP-0xC] ; VAR:pfp <p +e_cbframe *> 0x363DF6: CMP DWORD PTR [EAX+0x8],0x0 0x363DFA: JNZ 0x363E1F ; (*+0x25) ; ev.c - Line 197 ; pfp->stats = Estat.enter(CurCBFrame, pfp->ev->up->max_cb_t +m); 0x363DFC: MOV EAX,DWORD PTR [EBP-0xC] ; VAR:pfp <p +e_cbframe *> 0x363DFF: MOV EAX,DWORD PTR [EAX] 0x363E01: MOV EAX,DWORD PTR [EAX+0x8] 0x363E04: MOVSX EAX,DWORD PTR [EAX+0x48] 0x363E08: PUSH EAX 0x363E09: PUSH DWORD PTR [0x10012020] 0x363E0F: CALL DWORD PTR [0x1001426C] 0x363E15: POP ECX 0x363E16: POP ECX 0x363E17: MOV ECX,DWORD PTR [EBP-0xC] ; VAR:pfp <p +e_cbframe *> 0x363E1A: MOV DWORD PTR [ECX+0x8],EAX ; ev.c - Line 198 ; else 0x363E1D: JMP 0x363E2C ; (*+0xF) ; ev.c - Line 199 ; Estat.resume(pfp->stats); 0x363E1F: MOV EAX,DWORD PTR [EBP-0xC] ; VAR:pfp <p +e_cbframe *>; <==0x00363DFA(*-0x25) 0x363E22: PUSH DWORD PTR [EAX+0x8] 0x363E25: CALL DWORD PTR [0x10014274] 0x363E2B: POP ECX ; ev.c - Line 203 ; } ; } ; /* this must be last because it can destroy the watcher */ ; pe_event_release(ev); 0x363E2C: PUSH DWORD PTR [EBP-0x4] ; VAR:ev <pe +_event *>; <==0x00363DE1(*-0x4B), 0x00363E1D(*-0xF), 0x00363DB7(*-0x7 +5) 0x363E2F: CALL 0x363E37 ; SYM:pe_eve +nt_release <Void> 0x363E34: POP ECX ; ev.c - Line 204 ; } 0x363E35: LEAVE 0x363E36: RET ;******************************************************************* +*************

    And a stack trace:

    PID: 4020 TID: 4192 - Stack Contents for 0x00363D7C 0x00363D7C: Event.dll:pe_event_postCB + 0x0025 <Void> 0x00363C6F: Event.dll:pe_event_invoke + 0x0738 <Void> 0x00364EA1: Event.dll:pe_empty_queue + 0x0031 <Int> 0x00364ACC: Event.dll:one_event + 0x00ED <Int> 0x280933F9: Perl_get_context + 0x001F 0x00365A0E: Event.dll:XS_Event__loop + 0x011B <Void> 0x2804002B: Perl_sv_compile_2op + 0x7B9F 0x2805D4AF: Perl_runops_standard + 0x000C 0x28088A87: RunPerl + 0x0086 0x77F53CB3: RtlDosPathNameToNtPathName_U + 0x02E3 0x00401012: 0x77E814C7: GetCurrentDirectoryW + 0x0044

    I'm intrigued by what you are trying to achieve by mixing these two anyway?


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.