[Vm-dev] Segmentation fault in MSYS2 MinGW w64 build

Eliot Miranda eliot.miranda at gmail.com
Sat Nov 24 19:31:22 UTC 2018


Hi Hernan,

> On Nov 23, 2018, at 11:48 PM, Hernán Morales Durand <hernan.morales at gmail.com> wrote:
> 
> 
> Hi Eliot,
> 
> El vie., 23 nov. 2018 a las 14:52, Eliot Miranda
> (<eliot.miranda at gmail.com>) escribió:
>> 
>> 
>> Hi Hernan,
>> 
>>> On Nov 21, 2018, at 10:11 PM, Hernán Morales Durand <hernan.morales at gmail.com> wrote:
>>> 
>>> 
>>> Hi,
>>> 
>>> I wonder how do you guys approach a VM segfault, since I don't use to
>>> compile the VM and I could use your valuable experience. I am
>>> compiling pharo.cog.spur on Windows 8.1. Segfault is raised when
>>> opening the image (not on querying --version for example). These could
>>> be quite generic questions but I look for insights to get the right
>>> workflow:
>>> 
>>> 1) Do you perform a static analysis at some point? (nm, ldd,
>>> objdump,... is it worth it when you have the VM sources?)
>> 
>> No.  The bug must be determined, which implies a case analysis to localize the bug.  The first case is: is the image corrupt or not?  Looking at a stack trace in gdb or in the crash.dmp can show if the image is crashing because it is invoking something (eg an FFI call). The leak checker can find leaks in the image at start up.  If the image looks ok then it’s a vm bug, or an FFI bug, and one wants to narrow down, using the simulator or gdb and/or assert and debug VMs and try and define a reproducible case.
> 
> Ok, I narrowed it down so far to sqWin32Utils.c. The problem is I was
> specifying a run Pharo.image and image file simply wasn't there so my
> mistake however IMO the VM shouldn't segfault just because of that:

that’s really funny!  So it segfault because it is trying to report a stack backtrace on exit when there is no stack :-). This should be easy to fix :-). Thank you!

_,,,^..^,,,_ (phone)
> 
> Thread 1 hit Breakpoint 3, abortMessage (
>    fmt=0x6930d3 <reverse_image_bytes.reverseBits+2327> "Could not
> open the Pharo Virtual Machine image file '%s'\n\nThere are several
> ways to open an image file. You can:\n  1. Double-click on the desired
> image file.\n  2. Drop the image file onto the applicat"...) at
> ../../platforms/win32/vm\sqWin32Utils.c:147
> 147             va_start(args, fmt);
> (gdb) where
> #0  abortMessage (
>    fmt=0x6930d3 <reverse_image_bytes.reverseBits+2327> "Could not
> open the Pharo Virtual Machine image file '%s'\n\nThere are several
> ways to open an image file. You can:\n  1. Double-click on the desired
> image file.\n  2. Drop the image file onto the applicat"...) at
> ../../platforms/win32/vm\sqWin32Utils.c:147
> #1  0x0000000000537ad7 in printUsage (level=2)
>    at ../../platforms/win32/vm\sqWin32Window.c:3357
> #2  0x000000000052d0fd in sqMain (argc=2, argv=0x395fc0)
>    at ../../platforms/win32/vm\sqWin32Main.c:1624
> #3  0x000000000052d6ab in WinMain (hInst=0x400000, hPrevInstance=0x0,
>    lpCmdLine=0xb42ce "Pharo.image", nCmdShow=10)
>    at ../../platforms/win32/vm\sqWin32Main.c:1793
> #4  0x00000000004013a5 in __tmainCRTStartup ()
>    at C:/repo/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:339
> #5  0x000000000040150b in mainCRTStartup ()
>    at C:/repo/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:223
> (gdb) s
> 148             if (fIsConsole) {
> (gdb) n
> 152                     vfprintf(stderr, fmt, args);
> (gdb) n
> 154                     exit(-1);
> (gdb) n
> 
> Thread 1 received signal SIGSEGV, Segmentation fault.
> 0x00000000004767cb in activeProcess ()
>    at ../../spur64src/vm\gcc3x-cointerp.c:62062
> 62062           objOop1 = longAt((GIV(specialObjectsOop) +
> BaseHeaderSize) + (((sqInt)((usqInt)(SchedulerAssociation) <<
> (shiftForWord())))));
> 
> AFAIK it could be possible the segfault is produced between the exit
> and the activeProcess() line while unwiding or just returning from
> stack.
> 
>> 
>>> 2) I can safely assume the debug flags -g -O0 -fbuiltin and others are
>>> already enabled somewhere when using mvm -d, or should I add/check
>>> something else?
>> 
>> I don’t understand.  mcm -d guarantees -O0 and enables asserts; the other flags are platform specific.
> 
> Got it :)
> 
>> 
>>> Just in case anyone want to have a look to my LOGD output:
>> 
>> Why do you suspect your vm? Does the image crash with a standard vm or not?
> 
> No it doesn't, the only thing I did so far is compiling under Windows
> using MinGW64. So I didn't touched a single line in the VM.
> I read people is compiling using Cygwin maybe there are some relevant
> differences, I really don't know but will have a better look.
> 
> Cheers,
> 
> Hernán
> 
> 
> 
> Are you developing your Type Collection support?  If the latter does
> it work in the simulator?  What is a minimal example that causes a
> crash *without* user input?  This is very important.  Try and develop
> a doit, either supplied at image startup or a doit that starts by
> doing a snapshot so that the doit runs at startup without user input
> and is therefore repeatable.  On each subsequent run you can then set
> breakpoints to get nearer the cause of the bug.
>> 
>>> 
>>> https://gist.github.com/hernanmd/f8ae1be9d1a9167a61143030a47c9a4b
>>> 
>>> gcc defs output:
>>> 
>>> https://gist.github.com/hernanmd/384a4303a23fe86a0e25a505fa3dc7ef
>>> 
>>> $ ulimit
>>> unlimited
>>> 
>>> $ gcc -v
>>> Using built-in specs.
>>> COLLECT_GCC=C:\msys64\mingw64\bin\gcc.exe
>>> COLLECT_LTO_WRAPPER=C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.2.0/lto-wrapper.exe
>>> Target: x86_64-w64-mingw32
>>> Configured with: ../gcc-8.2.0/configure --prefix=/mingw64
>>> --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32
>>> --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
>>> --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include
>>> --libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64
>>> --with-tune=generic
>>> --enable-languages=ada,c,lto,c++,objc,obj-c++,fortran --enable-shared
>>> --enable-static --enable-libatomic --enable-threads=posix
>>> --enable-graphite --enable-fully-dynamic-string
>>> --enable-libstdcxx-filesystem-ts=yes --enable-libstdcxx-time=yes
>>> --disable-libstdcxx-pch --disable-libstdcxx-debug
>>> --disable-isl-version-check --enable-lto --enable-libgomp
>>> --disable-multilib --enable-checking=release --disable-rpath
>>> --disable-win32-registry --disable-nls --disable-werror
>>> --disable-symvers --with-libiconv --with-system-zlib
>>> --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64
>>> --with-isl=/mingw64 --with-pkgversion='Rev3, Built by MSYS2 project'
>>> --with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as
>>> --with-gnu-ld
>>> Thread model: posix
>>> gcc version 8.2.0 (Rev3, Built by MSYS2 project)
>>> 
>>> Finally my gdb session
>>> 
>>> (gdb) run Pharo.image
>>> Starting program:
>>> C:\git_projects\opensmalltalk-vm\build.win64x64\pharo.cog.spur\builddbg\vm\Pharo.exe
>>> Pharo.image
>>> [New Thread 9516.0x134c]
>>> [New Thread 9516.0xff0]
>>> [New Thread 9516.0xe58]
>>> [New Thread 9516.0xd88]
>>> [New Thread 9516.0x1924]
>>> [New Thread 9516.0x13a4]
>>> [New Thread 9516.0x27b0]
>>> [New Thread 9516.0x1c44]
>>> [New Thread 9516.0x162c]
>>> [New Thread 9516.0x1ee0]
>>> [New Thread 9516.0x1130]
>>> [New Thread 9516.0x82c]
>>> [Thread 9516.0x82c exited with code 0]
>>> [New Thread 9516.0x274c]
>>> [New Thread 9516.0x1544]
>>> [New Thread 9516.0x1ed4]
>>> [New Thread 9516.0x1094]
>>> [New Thread 9516.0xc6c]
>>> [Thread 9516.0xc6c exited with code 0]
>>> [New Thread 9516.0x15d8]
>>> [Thread 9516.0xff0 exited with code 0]
>>> [Thread 9516.0x274c exited with code 0]
>>> [Thread 9516.0x1544 exited with code 0]
>>> 
>>> Thread 1 received signal SIGSEGV, Segmentation fault.
>>> 0x00000000004767cb in activeProcess ()
>>>   at ../../spur64src/vm\gcc3x-cointerp.c:62062
>>> 62062           objOop1 = longAt((GIV(specialObjectsOop) +
>>> BaseHeaderSize) + (((sqInt)((usqInt)(SchedulerAssociation) <<
>>> (shiftForWord())))));
>>> 
>>> (gdb) where
>>> #0  0x00000000004767cb in activeProcess ()
>>>   at ../../spur64src/vm\gcc3x-cointerp.c:62062
>>> #1  0x000000000047b9bd in printCallStack ()
>>>   at ../../spur64src/vm\gcc3x-cointerp.c:69094
>>> #2  0x000000000052ca05 in dumpStackIfInMainThread (optionalFile=0x0)
>>>   at ../../platforms/win32/vm\sqWin32Main.c:1027
>>> #3  0x000000000052cba0 in Cleanup ()
>>>   at ../../platforms/win32/vm\sqWin32Main.c:1366
>>> #4  0x00007ffb2e726e1f in msvcrt!_flushall ()
>>>  from C:\WINDOWS\system32\msvcrt.dll
>>> #5  0x000000000053842d in abortMessage (
>>>   fmt=0x6930d3 <reverse_image_bytes.reverseBits+2327> "Could not
>>> open the Pharo Virtual Machine image file '%s'\n\nThere are several
>>> ways to open an image file. You can:\n  1. Double-click on the desired
>>> image file.\n  2. Drop the image file onto the applicat"...) at
>>> ../../platforms/win32/vm\sqWin32Utils.c:154
>>> #6  0x0000000000537ad7 in printUsage (level=2)
>>>   at ../../platforms/win32/vm\sqWin32Window.c:3357
>>> #7  0x000000000052d0fd in sqMain (argc=2, argv=0x325f30)
>>>   at ../../platforms/win32/vm\sqWin32Main.c:1624
>>> #8  0x000000000052d6ab in WinMain (hInst=0x400000, hPrevInstance=0x0,
>>>   lpCmdLine=0x184217 "Pharo.image", nCmdShow=10)
>>>   at ../../platforms/win32/vm\sqWin32Main.c:1793
>>> #9  0x00000000004013a5 in __tmainCRTStartup ()
>>>   at C:/repo/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:339
>>> #10 0x00000000004014db in WinMainCRTStartup ()
>>>   at C:/repo/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:195
>>> 
>>> (gdb) bt full
>>> #0  0x00000000004767cb in activeProcess ()
>>>   at ../../spur64src/vm\gcc3x-cointerp.c:62062
>>>       objOop = 3670016
>>>       objOop1 = 5415761
>>> #1  0x000000000047b9bd in printCallStack ()
>>>   at ../../spur64src/vm\gcc3x-cointerp.c:69094
>>> No locals.
>>> #2  0x000000000052ca05 in dumpStackIfInMainThread (optionalFile=0x0)
>>>   at ../../platforms/win32/vm\sqWin32Main.c:1027
>>> No locals.
>>> #3  0x000000000052cba0 in Cleanup ()
>>>   at ../../platforms/win32/vm\sqWin32Main.c:1366
>>> No locals.
>>> #4  0x00007ffb2e726e1f in msvcrt!_flushall ()
>>>  from C:\WINDOWS\system32\msvcrt.dll
>>> No symbol table info available.
>>> #5  0x000000000053842d in abortMessage (
>>>   fmt=0x6930d3 <reverse_image_bytes.reverseBits+2327> "Could not
>>> open the Pharo Virtual Machine image file '%s'\n\nThere are several
>>> ways to open an image file. You can:\n  1. Double-click on the desired
>>> image file.\n  2. Drop the image file onto the applicat"...) at
>>> ../../platforms/win32/vm\sqWin32Utils.c:154
>>>       buf = 0x10000000100 <error: Cannot access memory at address
>>> 0x10000000100>
>>>       args = 0x106f7b8 "\024▒w"
>>> #6  0x0000000000537ad7 in printUsage (level=2)
>>>   at ../../platforms/win32/vm\sqWin32Window.c:3357
>>> No locals.
>>> #7  0x000000000052d0fd in sqMain (argc=2, argv=0x385f30)
>>>   at ../../platforms/win32/vm\sqWin32Main.c:1624
>>>       virtualMemory = 0
>>> #8  0x000000000052d6ab in WinMain (hInst=0x400000, hPrevInstance=0x0,
>>>   lpCmdLine=0x154217 "Pharo.image", nCmdShow=10)
>>>   at ../../platforms/win32/vm\sqWin32Main.c:1793
>>> No locals.
>>> #9  0x00000000004013a5 in __tmainCRTStartup ()
>>>   at C:/repo/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:339
>>>       lock_free = <optimized out>
>>>       fiberid = <optimized out>
>>>       nested = <optimized out>
>>>       lpszCommandLine = <optimized out>
>>>       StartupInfo = {cb = 104, lpReserved = 0x15b870 "",
>>>         lpDesktop = 0x15b700 "Default",
>>>         lpTitle = 0x1576b0
>>> "C:\\git_projects\\opensmalltalk-vm\\build.win64x64\\pharo.cog.spur\\builddbg\\vm\\Pharo.exe",
>>> dwX = 0, dwY = 0, dwXSize = 0,
>>>         dwYSize = 0, dwXCountChars = 0, dwYCountChars = 0,
>>>         dwFillAttribute = 0, dwFlags = 0, wShowWindow = 0, cbReserved2 = 0,
>>>         lpReserved2 = 0x0, hStdInput = 0xffffffffffffffff,
>>>         hStdOutput = 0xffffffffffffffff, hStdError = 0xffffffffffffffff}
>>>       inDoubleQuote = <optimized out>
>>> #10 0x00000000004014db in WinMainCRTStartup ()
>>>   at C:/repo/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:195
>>>       ret = 255
>>> 
>>> I can see it belongs to :
>>> 
>>> /*    Answer the current activeProcess. */
>>> /*    useful for VM debugging */
>>> 
>>>   /* StackInterpreter>>#activeProcess */
>>> sqInt
>>> activeProcess(void)
>>> {   DECL_MAYBE_SQ_GLOBAL_STRUCT
>>>   sqInt objOop;
>>>   sqInt objOop1;
>>> 
>>>   /* begin fetchPointer:ofObject: */
>>>   objOop1 = longAt((GIV(specialObjectsOop) + BaseHeaderSize) +
>>> (((sqInt)((usqInt)(SchedulerAssociation) << (shiftForWord())))));
>>>   objOop = longAt((objOop1 + BaseHeaderSize) +
>>> (((sqInt)((usqInt)(ValueIndex) << (shiftForWord())))));
>>>   return longAt((objOop + BaseHeaderSize) +
>>> (((sqInt)((usqInt)(ActiveProcessIndex) << (shiftForWord())))));
>>> }
>>> 
>>> but apart from that I don't know how to continue stepping... any hints?
>>> 
>>> Cheers,
>>> 
>>> Hernán
>>> 
>>> El mié., 21 nov. 2018 a las 3:11, Hernán Morales Durand
>>> (<hernan.morales at gmail.com>) escribió:
>>>> 
>>>> El mar., 20 nov. 2018 a las 11:11, Alistair Grant
>>>> (<akgrant0710 at gmail.com>) escribió:
>>>>> 
>>>>> 
>>>>> Hi Hernán,
>>>>> 
>>>>> 
>>>>> On Tue, 20 Nov 2018 at 14:47, Hernán Morales Durand
>>>>> <hernan.morales at gmail.com> wrote:
>>>>>> 
>>>>>> 
>>>>>> Hi guys,
>>>>>> 
>>>>>> I manged to build the pharo.cog.spur VM in a MSYS2 MinGW w64 system. This means:
>>>>>> 
>>>>>> cd build.win64x64/pharo.cog.spur/
>>>>>> ./mvm -d -- TOOLPREFIX=''
>>>>>> 
>>>>>> and
>>>>>> 
>>>>>> cd build.win64x64/pharo.cog.spur/
>>>>>> ./mvm -f -- TOOLPREFIX=''
>>>>>> 
>>>>>> However the VM produces a segmentation fault on running an image.
>>>>>> 
>>>>>> Before jumping into gdb, is there a way to clean everything produced
>>>>>> by mvm like a fresh cloned repository? I tried make clean but doesn't
>>>>>> remove any third-party libraries.
>>>>>> 
>>>>>> Besides I would like to compare with the appveyor build.
>>>>> 
>>>>> I use:
>>>>> 
>>>>> git clean -fdX .
>>>>> 
>>>>> You can do a test run with:
>>>>> 
>>>>> git clean -fdXn .
>>>>> 
>>>>> git clean --help
>>>>> 
>>>>> is worth a read.
>>>>> 
>>>> 
>>>> Thanks Alistair, that did it.
>>>> 
>>>> Cheers,
>>>> 
>>>> Hernán
>>>> 
>>>>> HTH,
>>>>> Alistair


More information about the Vm-dev mailing list