Emulator sometimes dumps core on termination

[johnbeard]

• KOReader version: nightly
• Device: Emulator (Linux)

Issue

Sometimes (maybe half the time), killing the emulator window (I think with WM_DELETE) ends up dumping core to the console, which is a bit annoying because it spams ~750 lines to the console when you want to look at some recent output.

Steps to reproduce

• Start emulator
• Kill it
• Log spam ensues, sometimes.

coredump.txt

[NiLuJe]

That's mesa imploding. Has happened randomly since basically forever in my own experience.

IIRC, also happened back when I was using an nvidia card a few years ago.

[NiLuJe]

Not using catchsegv might just be enough to sweep it under the rug, because, ironically enough, I've never had it happen under gdb/valgrind ;p.

[Frenzie]

I like catchsegv because it can occasionally provide a hint to some mysterious issue.

Imo the solution to the problem in the OP is just to use ctrl+c in the terminal as opposed to force killing it with WM_DELETE.

[johnbeard]

Sure, it's not a critical issue, just a bit annoying when I hit Mod-Shift-Q on autopilot and nuke my console's buffer.

[NiLuJe]

Oh, it happens on perfectly sane exits on my end, no need for anything funky, FWIW ;).

[Frenzie]

I have seen it on occasion, but I can't reproduce it with xkill. I'd be inclined to think it's an issue we should fix rather than hide though? ;-)

[NiLuJe]

I'll see if I can get an actual coredump and not just catchsegv getting its panties in a twist... ;).

[NiLuJe]

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f0aa155635e in __pthread_clockjoin_ex () from /lib64/libpthread.so.0
(gdb) bt full
#0  0x00007f0aa155635e in __pthread_clockjoin_ex () from /lib64/libpthread.so.0
No symbol table info available.
#1  0x00007f0a9ff38fc7 in util_queue_kill_threads () from /usr/lib64/dri/radeonsi_dri.so
No symbol table info available.
#2  0x00007f0a9ff3907c in atexit_handler () from /usr/lib64/dri/radeonsi_dri.so
No symbol table info available.
#3  0x00007f0aa1a67513 in __run_exit_handlers () from /lib64/libc.so.6
No symbol table info available.
#4  0x00007f0aa1a676ba in exit () from /lib64/libc.so.6
No symbol table info available.
#5  0x00005569f567aacb in lj_cf_os_exit (L=0x7f0aa1d57380) at lib_os.c:121
        status = 0
#6  0x00005569f564d5b5 in lj_BC_FUNCC () at buildvm_x86.dasc:849
No locals.
#7  0x00005569f563cec3 in lua_pcall (L=L@entry=0x7f0aa1d57380, nargs=nargs@entry=3, nresults=-1, errfunc=errfunc@entry=2) at lj_api.c:1169
        g = 0x7f0aa1d573e0
        oldh = 0 '\000'
        ef = 40
        status = <optimized out>
#8  0x00005569f5632956 in docall (L=L@entry=0x7f0aa1d57380, narg=narg@entry=3, clear=clear@entry=0) at luajit.c:121
        status = <optimized out>
        base = 2
#9  0x00005569f56331da in handle_script (L=L@entry=0x7f0aa1d57380, argx=argx@entry=0x7ffffcd7e030) at luajit.c:292
        narg = 3
        status = <optimized out>
        fname = <optimized out>
#10 0x00005569f56338dc in pmain (L=0x7f0aa1d57380) at luajit.c:553
        s = 0x5569f56a6350 <smain>
        argv = 0x7ffffcd7e028
        argn = 1
        flags = 0
#11 0x00005569f564d5b5 in lj_BC_FUNCC () at buildvm_x86.dasc:849
No locals.
#12 0x00005569f563cf16 in lua_cpcall (L=L@entry=0x7f0aa1d57380, func=func@entry=0x5569f5633772 <pmain>, ud=ud@entry=0x0) at lj_api.c:1197
        g = 0x7f0aa1d573e0
        oldh = 0 '\000'
        status = <optimized out>
#13 0x00005569f5633988 in main (argc=5, argv=0x7ffffcd7e028) at luajit.c:582
        status = <optimized out>
        L = 0x7f0aa1d57380

Wheeee!

[NiLuJe]

And I wasn't kidding when I said that getting rid of catchsegv fixes it ^^.

(As does running under gdb/valgrind... because it bypasses catchsegv ^^).

[Frenzie]

Fixed by #7044.