SEGSIGV running emulator on osx testing js library

[vidya88]

@olemis commented on Mar 13

Describe the bug
Emulator crashes running js lib test suite

Environment information:

• OS: Mac OS X
• Platform: Darwin 17.4.0 x86_64
• Firmware Version: working copy checked out at af9523f

Steps to Reproduce
I could reproduce this locally doing this

1. Install valgrind
2. Clone this repository
3. Run make clean && make emulator
4. Run valgrind ./emulator
5. Clone https://github.com/skycoin/hardware-wallet-js at 73add8b (recursive, update submodules) and switch to it
6. Run npm install && npm test

Actual behavior
Console output

$ valgrind ./emulator
==69087== Memcheck, a memory error detector
==69087== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==69087== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==69087== Command: ./emulator
==69087==
--69087-- run: /usr/bin/dsymutil "./emulator"
--69087-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option
--69087-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 2 times)
--69087-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 4 times)
==69087== Thread 2:
==69087== Invalid read of size 4
==69087== at 0x103FAFE9B: _pthread_wqthread (in /usr/lib/system/libsystem_pthread.dylib)
==69087== by 0x103FAFC4C: start_wqthread (in /usr/lib/system/libsystem_pthread.dylib)
==69087== Address 0x18 is not stack'd, malloc'd or (recently) free'd
==69087==
==69087==
==69087== Process terminating with default action of signal 11 (SIGSEGV)
==69087== Access not within mapped region at address 0x18
==69087== at 0x103FAFE9B: pthread_wqthread (in /usr/lib/system/libsystem_pthread.dylib)
==69087== by 0x103FAFC4C: start_wqthread (in /usr/lib/system/libsystem_pthread.dylib)
==69087== If you believe this happened as a result of a stack
==69087== overflow in your program's main thread (unlikely but
==69087== possible), you can try to increase the size of the
==69087== main thread stack using the --main-stacksize= flag.
==69087== The main thread stack size used in this run was 8388608.
--69087:0:schedule VG(sema_down): read returned -4

valgrind: m_scheduler/scheduler.c:1002 (void run_thread_for_a_while(HWord *, Int *, ThreadId, HWord, Bool)): Assertion 'VG_(in_generated_code) == False' failed.

host stacktrace:
==69087== at 0x2580412B1: ???
==69087== by 0x258041616: ???
==69087== by 0x2580415F6: ???
==69087== by 0x2580B7470: ???
==69087== by 0x2580B5676: ???
==69087== by 0x2580C6A53: ???
==69087== by 0x2580C6D10: ???

sched status:
running_tid=3

Thread 1: status = VgTs_WaitSys syscall unix:368 (lwpid 771)
==69087== at 0x103F7A562: __workq_kernreturn (in /usr/lib/system/libsystem_kernel.dylib)
==69087== by 0x103FAFC27: _pthread_workqueue_addthreads (in /usr/lib/system/libsystem_pthread.dylib)
==69087== by 0x103B9FE4D: _dispatch_global_queue_poke_slow (in /usr/lib/system/libdispatch.dylib)
==69087== by 0x103BA71BD: _dispatch_mach_send_push (in /usr/lib/system/libdispatch.dylib)
==69087== by 0x103BAB8C8: _voucher_activity_debug_channel_init (in /usr/lib/system/libdispatch.dylib)
==69087== by 0x103BA9AFC: _dispatch_kq_poll (in /usr/lib/system/libdispatch.dylib)
==69087== by 0x103BA9735: _dispatch_kq_drain (in /usr/lib/system/libdispatch.dylib)
==69087== by 0x103BA8B03: _dispatch_kq_unote_update (in /usr/lib/system/libdispatch.dylib)
==69087== by 0x103BA3E33: _dispatch_source_refs_register (in /usr/lib/system/libdispatch.dylib)
==69087== by 0x103BA3F5D: _dispatch_source_finalize_activation (in /usr/lib/system/libdispatch.dylib)
==69087== by 0x103B9CF49: _dispatch_queue_resume_finalize_activation (in /usr/lib/system/libdispatch.dylib)
==69087== by 0x103F414F6: _notify_lib_init (in /usr/lib/system/libsystem_notify.dylib)
==69087== by 0x103F41B89: notify_register_dispatch (in /usr/lib/system/libsystem_notify.dylib)
==69087== by 0x102D9F977: CFUniCharPrecompose (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation)
==69087== by 0x103B8BD4F: _dispatch_client_callout (in /usr/lib/system/libdispatch.dylib)
==69087== by 0x103B8BD02: dispatch_once_f (in /usr/lib/system/libdispatch.dylib)
==69087== by 0x102D9F82D: CFUniCharPrecompose (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation)
==69087== by 0x102C5A430: ___CFGetCachedUnsandboxedHomeDirectoryForUser_block_invoke (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation)
==69087== by 0x102DE2FD6: -[NSOrderedSet objectsWithOptions:passingTest:] (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation)
==69087== by 0x102DE427E: +[NSOrderedSet orderedSetWithObjects:count:] (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation)
==69087== by 0x102DE2D12: -[NSOrderedSet objectWithOptions:passingTest:] (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation)
==69087== by 0x102DE2BA4: -[NSOrderedSet isSubsetOfSet:] (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation)
==69087== by 0x102E08D22: __CFGenerateReport (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation)
==69087== by 0x102C62472: -[_CFXNotificationRegistrationContainer initWithParent:childKeyCallbacks:] (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation)
==69087== by 0x104908D26: ??? (in /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation)
==69087== by 0x10490873B: ??? (in /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation)
==69087== by 0x1013666FA: +[NSApplication initialize] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit)
==69087== by 0x1003522DD: set_bits(layout_bitmap, unsigned long, unsigned long) (in /usr/lib/libobjc.A.dylib)
==69087== by 0x1003433C8: _class_initialize (in /usr/lib/libobjc.A.dylib)
==69087== by 0x1003432FB: _class_initialize (in /usr/lib/libobjc.A.dylib)
==69087== by 0x100342E8E: lookUpImpOrForward (in /usr/lib/libobjc.A.dylib)
==69087== by 0x100342913: _objc_msgSend_uncached (in /usr/lib/libobjc.A.dylib)
==69087== by 0x1001BBB5C: Cocoa_RegisterApp (in /usr/local/Cellar/sdl2/2.0.9/lib/libSDL2-2.0.0.dylib)
==69087== by 0x1001C00AF: Cocoa_CreateDevice (in /usr/local/Cellar/sdl2/2.0.9/lib/libSDL2-2.0.0.dylib)
==69087== by 0x100197C77: SDL_VideoInit_REAL (in /usr/local/Cellar/sdl2/2.0.9/lib/libSDL2-2.0.0.dylib)
==69087== by 0x1001246BB: SDL_InitSubSystem_REAL (in /usr/local/Cellar/sdl2/2.0.9/lib/libSDL2-2.0.0.dylib)
==69087== by 0x10002582D: oledInit (oled.c:51)
==69087== by 0x100000C1B: main (main.c:33)
client stack range: [0x104106000 0x104905FFF] client SP: 0x104904808
valgrind stack range: [0x7000009B6000 0x700000AB5FFF] top usage: 9784 of 1048576

Thread 2: status = VgTs_Yielding (lwpid 2563)
==69087== at 0x103FAFE9B: _pthread_wqthread (in /usr/lib/system/libsystem_pthread.dylib)
==69087== by 0x103FAFC4C: start_wqthread (in /usr/lib/system/libsystem_pthread.dylib)
client stack range: ??????? client SP: 0x70000EE84A70
valgrind stack range: [0x700003FA5000 0x7000040A4FFF] top usage: 3728 of 1048576

Thread 3: status = VgTs_Runnable (lwpid 3843)
==69087== at 0x103FAFC40: start_wqthread (in /usr/lib/system/libsystem_pthread.dylib)
client stack range: ??????? client SP: 0x70000EF07F80
valgrind stack range: [0x7000040A9000 0x7000041A8FFF] top usage: 5816 of 1048576

Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.

If that doesn't help, please report this bug to: www.valgrind.org

In the bug report, send all the above text, the valgrind
version, and what OS and version you are using. Thanks.

Expected behavior
hardware-wallet-js test suite executed , test success

Additional context
Bug detected in Travis build 163; linux job succeeds whereas osx job crashes.

[vidya88]

@olemis commented on Mar 28

@YuraYelisieiev it is possible to reproduce the issue with hw-go lib as well .

[vidya88]

@YuraYelisieiev commented on May 1

We cant memcheck emulator with Valgrind on MacOS, because new versions of the kernel are not supported.

[vidya88]

@YuraYelisieiev commented on May 1

They made a new release on April 19 2019, but the versions of MacOS software updating faster than Valgrind. So we need to find a new tool for memory check.

[vidya88]

@jdknives commented on Jul 17

I close this as it sounds there is nothing we can or should do about that.

[vidya88]

@olemis commented on Jul 17

@jdknives commented on Jul 17

I close this as it sounds there is nothing we can or should do about that.

No , please keep it open . This is a real issue that needs to be fixed to enable Travis CI for osx

[vidya88]

@olemis commented on Jul 17

@YuraYelisieiev commented on May 1

We cant memcheck emulator with Valgrind on MacOS, because new versions of the kernel are not supported.

@YuraYelisieiev once again , this is not related to the original problem . I'll assign this to someone else.

Valgrind is just a tool . The issue is not related to Valgrind . If not possible to use Valgrind then feel free to use something else or nothing at all . Issue needs to be fixed .

[vidya88]

@Macrosrider commented on Aug 20

On Windows all tests running without problems and crashes. So, it's definitely only MacOS issue

[vidya88]

@olemis commented on Aug 21

@Macrosrider commented on Aug 20

On Windows all tests running without problems and crashes. So, it's definitely only MacOS issue

thanks for pointer
👍