SIGSEGV icewm 3.0.1.7

[cgm999]

Hi, Easiest to reproduce this is with gpg -d ..

2.9.9.9 does not have the problem , from 3.0.1 up it seems that the bug manifests

==27786== Invalid read of size 8 ==27786== at 0x15DB34: getClientItem (wmclient.h:203) ==27786== by 0x15DB34: WindowList::insertApp(ClientListItem) (wmwinlist.cc:542) ==27786== by 0x1997B5: addToWindowList (wmframe.cc:295) ==27786== by 0x1997B5: YFrameWindow::addToWindowList() (wmframe.cc:291) ==27786== by 0x199E56: YFrameWindow::afterManage() (wmframe.cc:461) ==27786== by 0x1A4556: YFrameWindow::doManage(YFrameClient, bool&, bool&) (wmframe.cc:450) ==27786== by 0x182FF8: YWindowManager::manageClient(YFrameClient, bool) (wmmgr.cc:1744) ==27786== by 0x18378D: YWindowManager::mapClient(unsigned long) (wmmgr.cc:1883) ==27786== by 0x22670E: YXApplication::handleWindowEvent(unsigned long, _XEvent&) (yxapp.cc:1222) ==27786== by 0x2269E0: YXApplication::handleXEvents() (yxapp.cc:1183) ==27786== by 0x19631C: YWMApp::handleIdle() (wmapp.cc:1493) ==27786== by 0x20D7DC: YApplication::mainLoop() (yapp.cc:242) ==27786== by 0x195BF6: YWMApp::mainLoop() (wmapp.cc:1449) ==27786== by 0x149BFF: main (wmapp.cc:1842) ==27786== Address 0xc8 is not stack'd, malloc'd or (recently) free'd ==27786== ==27786== ==27786== Process terminating with default action of signal 11 (SIGSEGV) ==27786== Access not within mapped region at address 0xC8 ==27786== at 0x15DB34: getClientItem (wmclient.h:203) ==27786== by 0x15DB34: WindowList::insertApp(ClientListItem) (wmwinlist.cc:542) ==27786== by 0x1997B5: addToWindowList (wmframe.cc:295) ==27786== by 0x1997B5: YFrameWindow::addToWindowList() (wmframe.cc:291) ==27786== by 0x199E56: YFrameWindow::afterManage() (wmframe.cc:461) ==27786== by 0x1A4556: YFrameWindow::doManage(YFrameClient, bool&, bool&) (wmframe.cc:450) ==27786== by 0x182FF8: YWindowManager::manageClient(YFrameClient, bool) (wmmgr.cc:1744) ==27786== by 0x18378D: YWindowManager::mapClient(unsigned long) (wmmgr.cc:1883) ==27786== by 0x22670E: YXApplication::handleWindowEvent(unsigned long, _XEvent&) (yxapp.cc:1222) ==27786== by 0x2269E0: YXApplication::handleXEvents() (yxapp.cc:1183) ==27786== by 0x19631C: YWMApp::handleIdle() (wmapp.cc:1493) ==27786== by 0x20D7DC: YApplication::mainLoop() (yapp.cc:242) ==27786== by 0x195BF6: YWMApp::mainLoop() (wmapp.cc:1449) ==27786== by 0x149BFF: main (wmapp.cc:1842) ==27786== If you believe this happened as a result of a stack ==27786== overflow in your program's main thread (unlikely but ==27786== possible), you can try to increase the size of the ==27786== main thread stack using the --main-stacksize= flag. ==27786== The main thread stack size used in this run was 8388608. ==27786== ==27786== HEAP SUMMARY: ==27786== in use at exit: 1,379,627 bytes in 15,337 blocks ==27786== total heap usage: 68,056 allocs, 52,719 frees, 11,408,850 bytes allocated ==27786== ==27786== LEAK SUMMARY: ==27786== definitely lost: 1,792 bytes in 3 blocks ==27786== indirectly lost: 3,813 bytes in 120 blocks ==27786== possibly lost: 35,427 bytes in 1,053 blocks ==27786== still reachable: 1,336,579 bytes in 14,140 blocks ==27786== of which reachable via heuristic: ==27786== multipleinheritance: 32 bytes in 1 blocks ==27786== suppressed: 0 bytes in 0 blocks ==27786== Rerun with --leak-check=full to see details of leaked memory ==27786== ==27786== For lists of detected and suppressed errors, rerun with: -s ==27786== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

[misterfrumple]

Believe i am seeing a manifestation of this same problem. Upgraded from:

icewm.x86_64 2.9.9-1.fc36

to

icewm.x86_64 3.0.0-1.fc36

and any Java app opening a Swing interface now causes icewm to dump core (and restart icewm):

Oct 14 10:19:40 devsys systemd-coredump[2340]: Process 1789 (icewm) of user 2332 dumped core.

Downgrading back to 2.9.9-1 made the problem go away.

[gijsbers]

@cgm999 Should be fixed in af136ee53632932ca252ac0e6c42036029413493.

@misterfrumple The Java bug is unrelated to this one. It was reported before in ice-wm/icewm#93 and fixed in 3.0.1.

[gijsbers]

@cgm999 BTW, I can't execute your command gpg -d ..:

$ gpg -d .. >/dev/null
gpg: ..: read error: Is a directory

[misterfrumple]

Whoops! Very sorry about that. Thanks much for the note.

[cgm999]

@gijsbers Hi - yea I ment "gpg -d some_file" .. anyway I think you fixed the bug thank you very much!