Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Random crash when I am plotting using ggplotnim multiple times from the same nim compiled .so #50

Open
kaushalmodi opened this issue Mar 12, 2020 · 3 comments

Comments

@kaushalmodi
Copy link

kaushalmodi commented Mar 12, 2020

Hello,

I cannot find a way to reproduce this crash, but it happens may be once or twice in 1000+ invocations of the proc call that does the plotting using ggplotnim.

Here's what the sigusrdump.out looks like with paths renamed (libprj-64.so is nim built .so using --gc:none and C++ backend):

*** Current stack trace:
--> (nil)     <don't know>         + ffffffffffff0000
--> 0x31862325e5 gsignal              + 35      
--> 0x3186233dc5 abort                + 175     
--> 0x31862704f7 <don't know>         + 704f7   
--> 0x3186275f3e <don't know>         + 75f3e   
--> 0x3186278dd0 <don't know>         + 78dd0   
--> 0x7fa098789314 use_backtrace()   + f8       /path/to/libcbreakpad.so
--> 0x7fa09878960c cbpad_generate_dump_on_demand + 66       /path/to/libcbreakpad.so
--> 0x14ef7e2 <don't know>         + 10ef7e2 
--> 0x14efbc5 serror               + 95      
--> 0x98befe  <don't know>         + 58befe  
--> 0x3186e0f7e0 <don't know>         + f7e0    
--> 0x7fa063723410 <don't know>         + 32410    /path/to/lib/libcairo.so
--> 0x7fa0637658de <don't know>         + 748de    /path/to/lib/libcairo.so
--> 0x7fa0637570f3 <don't know>         + 660f3    /path/to/lib/libcairo.so
--> 0x7fa063757bbc <don't know>         + 66bbc    /path/to/lib/libcairo.so
--> 0x7fa063758848 <don't know>         + 67848    /path/to/lib/libcairo.so
--> 0x7fa063715350 <don't know>         + 24350    /path/to/lib/libcairo.so
--> 0x7fa063726ef3 <don't know>         + 35ef3    /path/to/lib/libcairo.so
--> 0x7fa06375bf53 <don't know>         + 6af53    /path/to/lib/libcairo.so
--> 0x7fa06371c5bd <don't know>         + 2b5bd    /path/to/lib/libcairo.so
--> 0x7fa06370faa7 cairo_stroke_preserve + 17       /path/to/lib/libcairo.so
--> 0x7fa063c651b0 <don't know>         + 591b0    /path/to/libprj/libprj_64.so
--> 0x7fa063c811c1 <don't know>         + 751c1    /path/to/libprj/libprj_64.so
--> 0x7fa063c82334 <don't know>         + 76334    /path/to/libprj/libprj_64.so
--> 0x7fa063c84768 <don't know>         + 78768    /path/to/libprj/libprj_64.so
--> 0x7fa063c84b5c <don't know>         + 78b5c    /path/to/libprj/libprj_64.so
--> 0x7fa063c850a4 <don't know>         + 790a4    /path/to/libprj/libprj_64.so
--> 0x7fa063c850a4 <don't know>         + 790a4    /path/to/libprj/libprj_64.so
--> 0x7fa063c851e5 <don't know>         + 791e5    /path/to/libprj/libprj_64.so
--> 0x7fa063cd5a98 <don't know>         + c9a98    /path/to/libprj/libprj_64.so
--> 0x7fa063cd5b33 <don't know>         + c9b33    /path/to/libprj/libprj_64.so
--> 0x7fa063cd5c1b <don't know>         + c9c1b    /path/to/libprj/libprj_64.so
--> 0x7fa063cdad07 <don't know>         + ced07    /path/to/libprj/libprj_64.so
--> 0x7fa063cdb198 cfft_psd_from_arrays + 1f1      /path/to/libprj/libprj_64.so
--> 0x7fa063cdb1fe cfft_from_arrays     + 5c       /path/to/libprj/libprj_64.so
--> 0x7fa08b62220b cfft_from_arrays     + 27947069 /path/to/libprj/libprj_64.so

Here's another backtrace info spit out by the xmsim app (that I use for SystemVerilog sims) that calls the plotting procs exported in the libprj_64.so:

xmsim: *F,SIGUSR: Unix Signal SIGSEGV raised from user application code.
*** glibc detected *** xmsim: free(): invalid next size (normal): 0x0000000017759be0 ***
======= Backtrace: =========
/lib64/libc.so.6[0x3186275f3e]
/lib64/libc.so.6[0x3186278dd0]
/path/to/lib/64bit/libcbreakpad.so(_Z13use_backtracev+0xf8)[0x7fa098789314]
/path/to/lib/64bit/libcbreakpad.so(cbpad_generate_dump_on_demand+0x66)[0x7fa09878960c]
xmsim[0x14ef7e2]
xmsim(serror+0x95)[0x14efbc5]
xmsim[0x98befe]
/lib64/libpthread.so.0[0x3186e0f7e0]
/path/to/lib/libcairo.so(+0x32410)[0x7fa063723410]
/path/to/lib/libcairo.so(+0x748de)[0x7fa0637658de]
/path/to/lib/libcairo.so(+0x660f3)[0x7fa0637570f3]
/path/to/lib/libcairo.so(+0x66bbc)[0x7fa063757bbc]
/path/to/lib/libcairo.so(+0x67848)[0x7fa063758848]
/path/to/lib/libcairo.so(+0x24350)[0x7fa063715350]
/path/to/lib/libcairo.so(+0x35ef3)[0x7fa063726ef3]
/path/to/lib/libcairo.so(+0x6af53)[0x7fa06375bf53]
/path/to/lib/libcairo.so(+0x2b5bd)[0x7fa06371c5bd]
/path/to/lib/libcairo.so(cairo_stroke_preserve+0x17)[0x7fa06370faa7]
/path/to/libprj/libprj_64.so(+0x591b0)[0x7fa063c651b0]
/path/to/libprj/libprj_64.so(+0x751c1)[0x7fa063c811c1]
/path/to/libprj/libprj_64.so(+0x76334)[0x7fa063c82334]
/path/to/libprj/libprj_64.so(+0x78768)[0x7fa063c84768]
/path/to/libprj/libprj_64.so(+0x78b5c)[0x7fa063c84b5c]
/path/to/libprj/libprj_64.so(+0x790a4)[0x7fa063c850a4]
/path/to/libprj/libprj_64.so(+0x790a4)[0x7fa063c850a4]
/path/to/libprj/libprj_64.so(+0x791e5)[0x7fa063c851e5]
/path/to/libprj/libprj_64.so(+0xc9a98)[0x7fa063cd5a98]
/path/to/libprj/libprj_64.so(+0xc9b33)[0x7fa063cd5b33]
/path/to/libprj/libprj_64.so(+0xc9c1b)[0x7fa063cd5c1b]
/path/to/libprj/libprj_64.so(+0xced07)[0x7fa063cdad07]
/path/to/libprj/libprj_64.so(cfft_psd_from_arrays+0x1f1)[0x7fa063cdb198]
/path/to/libprj/libprj_64.so(cfft_from_arrays+0x5c)[0x7fa063cdb1fe]

I am not sure if this kind of bug report helps you any to figure out what's causing this. But still I am documenting here whatever I have.

Versions

  • nim 1.0.2
  • ggplotnim 0.2.11
@kaushalmodi kaushalmodi changed the title Random crash when I am plotting using ggplotnim from the same nim compiled .so Random crash when I am plotting using ggplotnim multiple times from the same nim compiled .so Mar 12, 2020
@kaushalmodi
Copy link
Author

kaushalmodi commented Mar 12, 2020

I can reproduce this crash in ggplotnim 0.2.14 too. It's something to do with libpthread, libfontconfig and libfreetype.

Thread 0 (crashed)
 0  libcbreakpad.so + 0x2f2e0
    rax = 0x00007fa71207a5d4   rdx = 0x0000000000000000
    rcx = 0x00007fa7120a5b7d   rbx = 0x00007fa709f2c5c0
    rsi = 0x0000000000000001   rdi = 0x00007fa709f2bf78
    rbp = 0x00007fa709f2c530   rsp = 0x00007fa709f2bee0
     r8 = 0x0000000000000000    r9 = 0x0000000000000000
    r10 = 0x00000000160ad440   r11 = 0x0000000002be202c
    r12 = 0x00007fa709f2c8a8   r13 = 0x0000000000000000
    r14 = 0x00007fa709f2c540   r15 = 0x00007fa709f2cbb0
    rip = 0x00007fa7120a72e0
    Found by: given as instruction pointer in context
 1  libcbreakpad.so + 0x2d64e
    rbp = 0x00007fa709f2c660   rsp = 0x00007fa709f2c540
    rip = 0x00007fa7120a564e
    Found by: previous frame's frame pointer
 2  libc-2.12.so + 0x72248
    rbp = 0x00007fa709f2c660   rsp = 0x00007fa709f2c650
    rip = 0x00000036c5c72248
    Found by: stack scanning
 3  libfontconfig.so.1.8.0 + 0x8420
    rbp = 0x00007fa709f2c660   rsp = 0x00007fa709f2c660
    rip = 0x00007fa6dc410420
    Found by: stack scanning
 4  xmsim!vserror + 0x98
    rsp = 0x00007fa709f2c670   rip = 0x00000000014ee5f8
    Found by: stack scanning
 5  xmsim!serror + 0x95
    rbx = 0x0000000000000000   rbp = 0x00007fa709f2ca70
    rsp = 0x00007fa709f2c8a0   r12 = 0x00007fa709f2ca80
    r13 = 0x00007fa6d8090000   r14 = 0x00007fa6dc410420
    rip = 0x00000000014efbc5
    Found by: call frame info
 6  xmsim!sv_bushandler + 0x6b6
    rbx = 0xfffffffffffff970   rbp = 0x00007fa709f2ca70
    rsp = 0x00007fa709f2c980   r12 = 0x00007fa709f2ca80
    r13 = 0x00007fa6d8090000   r14 = 0x00007fa6dc410420
    rip = 0x000000000098a986
    Found by: call frame info
 7  libpthread-2.12.so + 0xf7e0
    rbx = 0x00007fa6d8090000   rbp = 0x00007fa709f2d100
    rsp = 0x00007fa709f2ca80   r12 = 0x00007fa709f2d190
    r13 = 0x000000000000001e   r14 = 0x000000000000001e
    r15 = 0x00000000160336c0   rip = 0x00000036c680f7e0
    Found by: call frame info
 8  0x7fa6d8090000
    rbp = 0x00007fa709f2d100   rsp = 0x00007fa709f2cb08
    rip = 0x00007fa6d8090000
    Found by: stack scanning
 9  libfontconfig.so.1.8.0 + 0x8420
    rbp = 0x00007fa709f2d100   rsp = 0x00007fa709f2cb30
    rip = 0x00007fa6dc410420
    Found by: stack scanning
10  0x7fa6d8090000
    rbp = 0x00007fa709f2d100   rsp = 0x00007fa709f2cb60
    rip = 0x00007fa6d8090000
    Found by: stack scanning
11  0x7fa6d8090000
    rbp = 0x00007fa709f2d100   rsp = 0x00007fa709f2cbc8
    rip = 0x00007fa6d8090000
    Found by: stack scanning
12  libfreetype.so.6.12.0 + 0x2db80
    rbp = 0x00007fa709f2d100   rsp = 0x00007fa709f2cbf0
    rip = 0x00007fa6dc19db80
    Found by: stack scanning
13  libfreetype.so.6.12.0 + 0x6b580
    rbp = 0x00007fa709f2d100   rsp = 0x00007fa709f2cbf8
    rip = 0x00007fa6dc1db580
    Found by: stack scanning
14  libfreetype.so.6.12.0 + 0x69b70
    rbp = 0x00007fa709f2d100   rsp = 0x00007fa709f2cc00
    rip = 0x00007fa6dc1d9b70
    Found by: stack scanning
15  libfreetype.so.6.12.0 + 0x6bd40
    rbp = 0x00007fa709f2d100   rsp = 0x00007fa709f2cc08
    rip = 0x00007fa6dc1dbd40
    Found by: stack scanning
16  libc-2.12.so + 0x7a459
    rbp = 0x00007fa709f2d100   rsp = 0x00007fa709f2cc40
    rip = 0x00000036c5c7a459
    Found by: stack scanning
17  xmsim!_fini + 0x56237f
    rbp = 0x00007fa709f2d100   rsp = 0x00007fa709f2cc48
    rip = 0x000000000220037f
    Found by: stack scanning
18  libm-2.12.so + 0x26487
    rbp = 0x00007fa709f2d100   rsp = 0x00007fa709f2cc50
    rip = 0x00000036c6426487
    Found by: stack scanning

@Vindaar
Copy link
Owner

Vindaar commented Mar 12, 2020

First of all thanks for the report!

Phew, that looks interesting (technically, it's probably a ginger bug, since it seems to be caused by cairo).
It's certainly possibly that I'm introducing some undefined behavior when using cairo. From what I can see from the stack trace it seems to be related to stroke_preserve, which is used in ginger for instance here:
https://github.com/Vindaar/ginger/blob/master/src/ginger/backendCairo.nim#L110
and in a couple other similar places (polyLine and rectangle).

Any chance you could run the code in debug build so that we might get a Nim stack trace of this? Or would the code be too slow?

Not yet sure how to debug this. It could of course (although unlikely) be some weird cairo bug as well. I'll think about it.

@kaushalmodi
Copy link
Author

Any chance you could run the code in debug build so that we might get a Nim stack trace of this?

I am trying to.. https://gitter.im/nim-lang/Nim?at=5e6a54d58011bb652a0c6906

I'll update here as soon as I have something more useful to share.

Thank you for looking into this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants