bbidulock / icewm

A window manager designed for speed, usability, and consistency
Other
590 stars 100 forks source link

icewm SIGSEGV #454

Closed cgm999 closed 4 years ago

cgm999 commented 4 years ago

Hi,

Tried versions 1.7.0.55 and 1.7.0.71 , and both gives SIGSEGV. Version 1.7.0.50 seems to work 798 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x20} --- 798 +++ killed by SIGSEGV (core dumped) +++

I'm on arch linux (kernel 5.4.54-1-lts ). Let me know what other details you need from me .

gijsbers commented 4 years ago

Thanks for the offer. Could you run it from valgrind? Like: valgrind /path/to/icewm Maybe first do a git pull and rebuild. It's now at 1.7.0.80.

cgm999 commented 4 years ago

OK this is icewm-git 1.7.0.82 compiled with -ggdb and other debug $ valgrind /tmp/icewm ==43821== Memcheck, a memory error detector ==43821== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==43821== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info ==43821== Command: /tmp/icewm ==43821== ==43821== Invalid read of size 8 ==43821== at 0x2056BA: YPixmap::verticalOffset() const (ypixmap.cc:203) ==43821== by 0x1EF89D: initPixmapOffsets (wpixres.cc:587) ==43821== by 0x1EF89D: WPixRes::initPixmaps() (wpixres.cc:615) ==43821== by 0x1865CB: YWMApp::YWMApp(int*, char*, char const, bool, char const, char const, char const) (wmapp.cc:1210) ==43821== by 0x14474A: main (wmapp.cc:1724) ==43821== Address 0x20 is not stack'd, malloc'd or (recently) free'd ==43821== ==43821== ==43821== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==43821== Access not within mapped region at address 0x20 ==43821== at 0x2056BA: YPixmap::verticalOffset() const (ypixmap.cc:203) ==43821== by 0x1EF89D: initPixmapOffsets (wpixres.cc:587) ==43821== by 0x1EF89D: WPixRes::initPixmaps() (wpixres.cc:615) ==43821== by 0x1865CB: YWMApp::YWMApp(int, char, char const, bool, char const, char const, char const) (wmapp.cc:1210) ==43821== by 0x14474A: main (wmapp.cc:1724) ==43821== If you believe this happened as a result of a stack ==43821== overflow in your program's main thread (unlikely but ==43821== possible), you can try to increase the size of the ==43821== main thread stack using the --main-stacksize= flag. ==43821== The main thread stack size used in this run was 8388608. ==43821== ==43821== HEAP SUMMARY: ==43821== in use at exit: 2,718,560 bytes in 1,628 blocks ==43821== total heap usage: 9,404 allocs, 7,776 frees, 5,729,062 bytes allocated ==43821== ==43821== LEAK SUMMARY: ==43821== definitely lost: 0 bytes in 0 blocks ==43821== indirectly lost: 0 bytes in 0 blocks ==43821== possibly lost: 1,480 bytes in 22 blocks ==43821== still reachable: 2,715,744 bytes in 1,596 blocks ==43821== of which reachable via heuristic: ==43821== length64 : 104 bytes in 2 blocks ==43821== newarray : 1,568 bytes in 18 blocks ==43821== suppressed: 0 bytes in 0 blocks ==43821== Rerun with --leak-check=full to see details of leaked memory ==43821== ==43821== For lists of detected and suppressed errors, rerun with: -s ==43821== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) Segmentation fault

gijsbers commented 4 years ago

Good! What is the theme you are using?

cgm999 commented 4 years ago

Theme="metal2/default.theme"

cgm999 commented 4 years ago

BTW I tried latest commit and the issue is fixed . TYVM! and keep up the good work!

gijsbers commented 4 years ago

Thanks for your cooperation! If you are happy with this you can close this issue.