[erlang-questions] dirty scheduler segfault

[Daniel Goertzen]

Thanks for trying it out.  That gist was a bit of a hash; apologies.

I made all the functions static and also put load and unload as NULL in
ERL_NIF_INIT, but I get the same results.

I ran it under valgrind and got...


# ERL_LIBS=.. valgrind --trace-children=yes erl

...

Eshell V6.2  (abort with ^G)

1>

1> dlibusb:mytest_io().

==9029== Thread 18:

==9029== Invalid read of size 4

==9029==    at 0x8190B56: process_main (beam_hot.h:935)

==9029==    by 0x80E565E: sched_thread_func (erl_process.c:7719)

==9029==    by 0x820982B: thr_wrapper (ethread.c:106)

==9029==    by 0x40FFF46: start_thread (in /lib/libpthread-2.20.so)

==9029==    by 0x41FE97D: clone (in /lib/libc-2.20.so)

==9029==  Address 0xfffffffe is not stack'd, malloc'd or (recently) free'd

==9029==

==9029==

==9029== Process terminating with default action of signal 11 (SIGSEGV)

==9029==  Access not within mapped region at address 0xFFFFFFFE

==9029==    at 0x8190B56: process_main (beam_hot.h:935)

==9029==    by 0x80E565E: sched_thread_func (erl_process.c:7719)

==9029==    by 0x820982B: thr_wrapper (ethread.c:106)

==9029==    by 0x40FFF46: start_thread (in /lib/libpthread-2.20.so)

==9029==    by 0x41FE97D: clone (in /lib/libc-2.20.so)

==9029==  If you believe this happened as a result of a stack

==9029==  overflow in your program's main thread (unlikely but

==9029==  possible), you can try to increase the size of the

==9029==  main thread stack using the --main-stacksize= flag.

==9029==  The main thread stack size used in this run was 8388608.

==9029==

==9029== HEAP SUMMARY:

==9029==     in use at exit: 9,020,474 bytes in 157 blocks

==9029==   total heap usage: 211 allocs, 54 frees, 9,490,700 bytes allocated

==9029==

==9029== LEAK SUMMARY:

==9029==    definitely lost: 0 bytes in 0 blocks

==9029==    indirectly lost: 0 bytes in 0 blocks

==9029==      possibly lost: 14,143 bytes in 41 blocks

==9029==    still reachable: 9,006,331 bytes in 116 blocks

==9029==         suppressed: 0 bytes in 0 blocks

==9029== Rerun with --leak-check=full to see details of leaked memory

==9029==

==9029== For counts of detected and suppressed errors, rerun with: -v

==9029== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

Killed


Line 935 of my beam_hot.h is...

OpCase(is_integer_fx): { BeamInstr* next; PreFetch(2, next);
IsInteger(xb(Arg(1)), ClauseFail()); // line 935 NextPF(2, next); }


I know little about beam internals. I don't know if this is useful.


On Fri, Oct 31, 2014 at 4:05 PM, Steve Vinoski <vinoski@REDACTED> wrote:

>
>
> On Fri, Oct 31, 2014 at 4:33 PM, Daniel Goertzen <
> daniel.goertzen@REDACTED> wrote:
>
>> I am seeing a segfault that seems to be related to dirty schedulers.
>> I've reduced the fault to the erlang and C nif module below which executes
>> the same nif with either the io dirty scheduler, the cpu dirty scheduler,
>> or the normal erlang scheduler.
>>
>>
>> When I start the emulator and run either dirty nif, I get a segfault. (
>> see https://gist.github.com/goertzenator/6237e0200a5f7bf22976)
>>
>
> I found it hard to make sense of what's in that gist due to the
> formatting, so I took your code and built it myself. When I ran it, it
> failed in your NIF load function, but it failed in a way that didn't make
> sense because all your function does is return 0. Then I realized none of
> your C functions were declared static, which means they are global, and I
> suspected your load() function was clashing with some other function of the
> same name. I made all your C functions static, rebuilt, and then ran
> everything and it seems like it worked:
>
> > c(dlibusb).
> Reading symbols for shared libraries . done
> {ok,dlibusb}
> 2> dlibusb:mytest_cpu().
> [ok,ok,ok,ok,ok,ok,ok,ok,ok,ok,ok]
> 3> dlibusb:mytest_io().
> [ok,ok,ok,ok,ok,ok,ok,ok,ok,ok,ok]
> 4> dlibusb:mytest_none().
> [ok,ok,ok,ok,ok,ok,ok,ok,ok,ok,ok]
>
> --steve
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20141031/3c065f8b/attachment.htm>