| Summary: | Spider segfaulting, new solver (417bdc2ec) bug? | ||
|---|---|---|---|
| Product: | [Applications] kpat | Reporter: | Duncan <1i5t5.duncan> |
| Component: | solver | Assignee: | Stephan Kulow <coolo> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | kde-games-bugs-null |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Duncan
2023-02-22 05:17:29 UTC
Bisecting confirms it's the new solver. 417bdc2ec (the new solver) bad. 3c581787e (the commit previous to that) seems to be fine. (Well, at least it played a full round without segfaulting, tho as I mentioned above that did happen -- once -- with the bad code, too.) Hi, can you export KDE_DEBUG=1 before starting it from console? Then something useful should appear in coredumpctl (typing from memory as I'm not having a computer around). (In reply to Stephan Kulow from comment #2) > Hi, can you export KDE_DEBUG=1 before starting it from console? Then > something useful should appear in coredumpctl (typing from memory as I'm not > having a computer around). Kernel CONFIG_COREDUMP=n, so coredumpctl never gets the cores from the kernel. I could change that if necessary (tho would rather not deal with figuring out all that config), but what about running via gdb instead? Meanwhile , dmesg does say SolverThread .... SIGSEGV ... error 6 in kpat ... Currently the gdb likely isn't much help due to stripped binaries, but here's what I get ATM... A bunch of New Thread ... Thread exited pairs, apparently one per move, I guess for the solver threads. Then at the SIGSEGV... [New Thread 0x7fffd99fc6c0 (LWP 13533)] Thread 381 "SolverThread" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffd99fc6c0 (LWP 13533)] 0x00005555555d762e in ?? () (gdb) bt #0 0x00005555555d762e in ?? () #1 0x00005555555d8546 in ?? () #2 0x00005555555d9726 in ?? () #3 0x00005555555da057 in ?? () #4 0x000055555558eab7 in ?? () #5 0x00007ffff64cb05f in ?? () from /usr/lib64/libQt5Core.so.5 #6 0x00007ffff5ee042d in ?? () from /usr/lib64/libc.so.6 #7 0x00007ffff5f5943c in ?? () from /usr/lib64/libc.so.6 (gdb) I'll have to look up again how to build unstripped, with debugging enabled (IIRC gentoo/kde has a guide I'll need to reread, I've done it once before for something and it wasn't difficult) to fill in the ??s. Hopefully this weekend... (In reply to Duncan from comment #3) > I'll have to look up again how to build unstripped, with debugging enabled This is more like it. (The -9999 bit is gentoo's normal live-git package version-numbering.) Again, a bunch of new-thread/thread-exited per-move as the solver-thread starts and exits, then... [New Thread 0x7fffd9da96c0 (LWP 74954)] Thread 159 "SolverThread" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffd9da96c0 (LWP 74954)] 0x00007ffff5ef3c0b in memmove () from /usr/lib64/libc.so.6 (gdb) bt #0 0x00007ffff5ef3c0b in memmove () from /usr/lib64/libc.so.6 #1 0x00005555555c060e in memcpy (__len=<optimized out>, __src=0x7fffb80ce700, __dest=0x7fffa4020ea8) at /include/bits/string_fortified.h:29 #2 Deck::update (this=this@entry=0x7fffa4020e28, other=other@entry=0x7fffb80ce680) at ../kpat-9999/src/patsolve/spidersolver2.cpp:656 #3 0x00005555555c169e in Deck::applyMove (this=this@entry=0x7fffb80ce680, m=..., newdeck=...) at ../kpat-9999/src/patsolve/spidersolver2.cpp:677 #4 0x00005555555c1bfd in Deck::shortestPath (this=<optimized out>, cap=cap@entry=150) at ../kpat-9999/src/patsolve/spidersolver2.cpp:802 #5 0x00005555555c1eaa in SpiderSolver2::patsolve (this=0x555556e473f0, max_positions=-1) at ../kpat-9999/src/patsolve/spidersolver2.cpp:941 #6 0x0000555555586979 in SolverThread::run (this=0x555555dddfe0) at ../kpat-9999/src/dealer.cpp:157 #7 0x00007ffff64cb05f in ?? () from /usr/lib64/libQt5Core.so.5 #8 0x00007ffff5ee042d in ?? () from /usr/lib64/libc.so.6 #9 0x00007ffff5f5943c in ?? () from /usr/lib64/libc.so.6 (gdb) glibc-2.36-r7 (r7 being the gentoo package revision), gcc-12.2.1_p20230121-r1, qtcore-5.15.8-r3. For the debug I built kpat with C(XX)FLAGS="-ggdb -Og", which I'll leave in place for the moment in case you need something beyond the simple bt. I will have to build myself with fortified to see what you see, but it's likely visible in valgrind as well - which is unfortunately too noisy for me at the moment (complaining about glibc and X11 even before kpat code runs). FORTIFY won't make a difference - and valgrind is silent. Can you please run kpat --solve 15 --end 1000 (this is two suits variant). What variant are you playing anyway? I managed to trigger it. I had to make my computer busy (your's is recompiling the world, right? :) and play in one suit variant and click like a maniac. ==2602== Thread 9 SolverThread: ==2602== Invalid write of size 8 ==2602== at 0x484E41B: memmove (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ==2602== by 0x46C539: UnknownInlinedFun (string_fortified.h:29) ==2602== by 0x46C539: Deck::update(Deck const*) (spidersolver2.cpp:656) ==2602== by 0x46D526: UnknownInlinedFun (spidersolver2.cpp:677) ==2602== by 0x46D526: UnknownInlinedFun (spidersolver2.cpp:802) ==2602== by 0x46D526: SpiderSolver2::patsolve(int) (spidersolver2.cpp:941) ==2602== by 0x423B86: SolverThread::run() (dealer.cpp:157) ==2602== by 0x5EE5E3C: QThreadPrivate::start(void*) (qthread_unix.cpp:330) ==2602== by 0x675698C: start_thread (in /usr/lib64/libc.so.6) ==2602== by 0x67DC343: clone (in /usr/lib64/libc.so.6) ==2602== Address 0x52dbf480 is 34,776,128 bytes inside a block of size 34,779,040 in arena "client" ==2602== ./bin/kpat --solve 14 --start 5 will reproduce the crash - I just had bad luck before. merged. Please give git a test. |