From: Jeremy W. <jez...@ho...> - 2005-10-15 22:25:36
|
Hi, perl.exe caused an Access Violation at location 7c93426d in module ntdll.dll Reading from location 00000000. Registers: eax=00000000 ebx=000001a4 ecx=00230ef0 edx=00000000 esi=002301a8 edi=002301c8 eip=7c93426d esp=0140efdc ebp=0140f1fc iopl=0 nv up ei pl zr na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246 Call stack: 7C93426D ntdll.dll:7C93426D RtlInitializeContext 77C2C3C9 MSVCRT.dll:77C2C3C9 free 77C2C3E7 MSVCRT.dll:77C2C3E7 free 77C2C42E MSVCRT.dll:77C2C42E malloc 2808991F perl58.dll:2808991F Perl_my_socketpair 28066038 perl58.dll:28066038 Perl_sv_setpvn 280693EB perl58.dll:280693EB Perl_newSVpv 28013436 perl58.dll:28013436 Perl_despatch_signals 2801328D perl58.dll:2801328D Perl_despatch_signals 280131CF perl58.dll:280131CF Perl_despatch_signals 28063230 perl58.dll:28063230 Perl_sv_2iv 233D1B39 GUI.dll:233D1B39 XS_Win32__GUI__Combobox_GetLBText(interpreter*, cv*) Combobox.c:626 void XS_Win32__GUI__Combobox_GetLBText(interpreter*, cv*)( PerlInterpreter * my_perl = &(indirect), CV * cv = &(indirect) ) This one is a little harder to reproduce, but I think it's easy enough to solve: [from line 399 in Combobox.xs] cbString = SendMessage(handle, CB_GETLBTEXTLEN, index, 0); if(cbString != LB_ERR) { szString = (char *) safemalloc(cbString); It looks like we're not allocating enough space for the string - adding 1 to cbString stops the crash (another issue is that we're assuming 1 byte = 1 char which might not be the case...). Cheers, jez. |
From: Jeremy W. <jez...@ho...> - 2005-10-16 08:14:00
|
Hi, > cbString = SendMessage(handle, CB_GETLBTEXTLEN, index, 0); > if(cbString != LB_ERR) { > szString = (char *) safemalloc(cbString); > I've just committed a fix for Combobox.xs (GetString) and Listbox.xs (GetString) - both weren't allocating enough space for the string (I added one to the length of the string). This bug would have been causing 'random' like problems as the buffer was overrun. From the look of things, Perl 5.8.7 would have been more susceptible than Perl 5.6.1 as memory is handled differently in that version of Perl. I checked all other safemalloc usage within Win32::GUI and everything else looks ok. However, there doesn't seem to be any consistency of how strings are allocated. Sometimes +1 is added sometimes +2 or even +16. All solutions aren't Unicode aware, and going forward it's probably a good idea to create a function/macro to handle the allocation of strings. Cheers, jez. |