Front page | perl.perl5.porters |
Postings from December 2012
[perl #115934] Crash in Strawberry Perl 64 5.16
Thread Previous
|
Thread Next
From:
bulk88 via RT
Date:
December 11, 2012 20:11
Subject:
[perl #115934] Crash in Strawberry Perl 64 5.16
Message ID:
rt-3.6.HEAD-17500-1355256667-1504.115934-15-0@perl.org
On Tue Dec 11 10:03:52 2012, jdb wrote:
>
> > Leon asked for a stack trace. Are you able to generate a textual
> stack trace?
>
> I think I can see the crashing instruction:
>
> perl516+1090d6
> 713c90d6 c7050000000000000000 mov dword ptr ds:[0],0
>
> I strongly suspect that this is the "free to wrong pool" error in
> win32/vmem.h:
>
> int *nowhere = NULL;
> Perl_warn(aTHX_ "Free to wrong pool %p not %p",this,ptr->owner);
> *nowhere = 0; /* this segfault is deliberate,
>
> I can see the list of loaded modules, but don't see any threading
> related (or incompatible) XS modules that may be obvious suspects, so
> I have no idea why that may have triggered.
Correct.
In 32 bit strawberry perl 5.16.1 (I dont have a 5.16.2 that is used by
the reporter), VMem::Free is
__________________________________________________________________
713C8F70 83 EC 1C sub esp,1Ch
713C8F73 89 5C 24 10 mov dword ptr [esp+10h],ebx
713C8F77 8B 5C 24 24 mov ebx,dword ptr [esp+24h]
713C8F7B 89 74 24 14 mov dword ptr [esp+14h],esi
713C8F7F 8B 74 24 20 mov esi,dword ptr [esp+20h]
713C8F83 89 7C 24 18 mov dword ptr [esp+18h],edi
713C8F87 85 DB test ebx,ebx
713C8F89 74 35 je 713C8FC0
713C8F8B 8B 7B FC mov edi,dword ptr [ebx-4]
713C8F8E 39 F7 cmp edi,esi
713C8F90 74 3E je 713C8FD0
713C8F92 85 FF test edi,edi
713C8F94 74 2A je 713C8FC0
713C8F96 E8 95 33 01 00 call 713DC330
713C8F9B 8B 53 FC mov edx,dword ptr [ebx-4]
713C8F9E 89 74 24 08 mov dword ptr [esp+8],esi
713C8FA2 C7 44 24 04 B8 5E 40 71 mov dword ptr [esp+4],71405EB8h
713C8FAA 89 54 24 0C mov dword ptr [esp+0Ch],edx
713C8FAE 89 04 24 mov dword ptr [esp],eax
713C8FB1 E8 6A 8F FF FF call 713C1F20
713C8FB6 C7 05 00 00 00 00 00 00 00 00 mov dword ptr ds:[0],0
713C8FC0 8B 5C 24 10 mov ebx,dword ptr [esp+10h]
713C8FC4 8B 74 24 14 mov esi,dword ptr [esp+14h]
713C8FC8 8B 7C 24 18 mov edi,dword ptr [esp+18h]
713C8FCC 83 C4 1C add esp,1Ch
713C8FCF C3 ret
_____________________________________________________________________
in the dump file provided I see
_____________________________________________________________________
713C9090 83 EC 1C sub esp,1Ch
713C9093 89 5C 24 10 mov dword ptr [esp+10h],ebx
713C9097 8B 5C 24 24 mov ebx,dword ptr [esp+24h]
713C909B 89 74 24 14 mov dword ptr [esp+14h],esi
713C909F 8B 74 24 20 mov esi,dword ptr [esp+20h]
713C90A3 89 7C 24 18 mov dword ptr [esp+18h],edi
713C90A7 85 DB test ebx,ebx
713C90A9 74 35 je 713C90E0
713C90AB 8B 7B FC mov edi,dword ptr [ebx-4]
713C90AE 39 F7 cmp edi,esi
713C90B0 74 3E je 713C90F0
713C90B2 85 FF test edi,edi
713C90B4 74 2A je 713C90E0
713C90B6 E8 95 33 01 00 call 713DC450
713C90BB 8B 53 FC mov edx,dword ptr [ebx-4]
713C90BE 89 74 24 08 mov dword ptr [esp+8],esi
713C90C2 C7 44 24 04 B8 5E 40 71 mov dword ptr [esp+4],71405EB8h
713C90CA 89 54 24 0C mov dword ptr [esp+0Ch],edx
713C90CE 89 04 24 mov dword ptr [esp],eax
713C90D1 E8 4A 8F FF FF call 713C2020
713C90D6 C7 05 00 00 00 00 00 00 00 00 mov dword ptr ds:[0],0
713C90E0 8B 5C 24 10 mov ebx,dword ptr [esp+10h]
713C90E4 8B 74 24 14 mov esi,dword ptr [esp+14h]
713C90E8 8B 7C 24 18 mov edi,dword ptr [esp+18h]
713C90EC 83 C4 1C add esp,1Ch
713C90EF C3 ret
_________________________________________________________________
Poor to no C debugging ability, is one of the reasons to not use
Strawberry Perl. GDB has many problems on windows in my personal
experience. No GUI, CL only, and .org w64 mingw fork problems, and if
the GDB isn't the one that compiled the perl image, erratic behavior or
GDB freezes. Last I checked strawberry does not include GDB. I don't
remember if GDB can use MS PDBs for MS DLL callstacks or not so
callstacks could be useless if a MS DLL was no frame pointer optimized
and it crashed.
To the OP, this might be a Perl the interpreter problem or an XS
problem. Its unknown unless someone else other than you can replicate,
or you provide a callstack of the crash. ActivePerl had a PDB symbol
file addon, (look for the "-symbols.zip" files). Extract the symbols
zip so each PDB file is in the same folder as the dll it shares its name
with. Then run the process with WinDbg (free) or Visual Studio (maybe
free/shareware by now, IDK, I have an old paid version) debuggers. When
the perl process crashes (and pauses and the debugger takes over
control), your callstack will be available going from VMem::Free going
back aslong as the debugger found the pdb files (slightly complicated,
enough writing for now for me).
--
bulk88 ~ bulk88 at hotmail.com
---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=115934
Thread Previous
|
Thread Next