Corinna Vinschen writes: > So with the latest snapshot we can at least see which DLL is affected > by this problem. Then we can check where this DLL is really supposed to > be in memory (objdump -h) and then we can check what really is at this > location in the process VM (/proc/$PID/maps)
Hello, I instrumented dll_list::alloc() a little bit - a now we will see the following. New code from Corinna and some other code ... $ ./forktest.pl start 0 [main] perl 8424 dll_list::alloc: alloc() - Error 396 [main] perl 8424 dll_list::alloc: C:\PROGRAMME\CYGWIN1710MINIMAL\bin\cygperl5_10.dll: Loaded to different address: parent(0xC40000) != child(0xB80000) 1116 [main] perl 8424 dll_list::alloc: data segment start: parent (0xD7A000) != child(0xCBA000) 1240 [main] perl 8424 dll_list::alloc: data segment end: parent(0xD991E0) ! = child(0xCD91E0) 1350 [main] perl 8424 dll_list::alloc: bss segment start: parent(0xD9C000) ! = child(0xCDC000) 1461 [main] perl 8424 dll_list::alloc: bss segment end: parent(0xD9C610) != child(0xCDC610) 1538 [main] perl 8424 dll_list::alloc: Long Sleep: 1h 1599 [main] perl 8424 dll_list::alloc: Sleep 100s With sysinternal tool vmmap I see the correct addresses of cygperl5_10.dll of the parent perl process (BSS and DATA) Using vmmap for the forked perl process is not possible - utility hangs - perhaps cause of hanging process?!? Similar problem looking into /proc/PID/map .... Why is this wrong mapping done? I figured our the following: Using SEP there is a service running called sysplant ("Application and Device Control", system32\Drivers\SysPlant.sys). Disabling this service on cmd line (cmd.exe) sc config sysplant start= disabled rebooting all seems to work fine! I will contact Symantec for more details about this service. The output of objdump -h is the following: $ objdump -h cygperl5_10.dll cygperl5_10.dll: file format pei-i386 Sections: Idx Name Size VMA LMA File off Algn 0 .text 001386fc 57011000 57011000 00000400 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA 1 .data 0001f1e4 5714a000 5714a000 00138c00 2**5 CONTENTS, ALLOC, LOAD, DATA 2 .rdata 00000780 5716a000 5716a000 00157e00 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .eh_frame 00000004 5716b000 5716b000 00158600 2**2 CONTENTS, ALLOC, LOAD, DATA 4 .bss 00000610 5716c000 5716c000 00000000 2**5 ALLOC 5 .edata 0000dcd0 5716d000 5716d000 00158800 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .idata 00001a08 5717b000 5717b000 00166600 2**2 CONTENTS, ALLOC, LOAD, DATA 7 .reloc 00008818 5717d000 5717d000 00168200 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 8 .gnu_debuglink 00000014 57186000 57186000 00170c00 2**2 CONTENTS, READONLY What is the recommended address layout? Should DATA be mapped to 0x5714a000 and BSS to 0x5716c000? Well - I just do the test again with disabled Symantec sysplant service. ... and ... voila ... Verifying address layout is: cygperl5_10.dll is loaded at address 0x50710000 and all addresses shown with objdump -h are used! That's really fine ... Thanks a lot Corinna and all others .... best regards Heiko -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple