You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When debugging an application, fvwm3 may completely freeze when a breakpoint is triggered while handling an event.
It's kind of difficult for me to come up with a minimal example that triggers this problem, but I've had this happen when debugging qt applications in qt creator, but also SDL applications with regular gdb. Whenever a breakpoint triggers somewhere in my gui event loop, the entire wm will freeze up. And it's not rare, unfortunately - it's common enough to be very annoying.
When this happens, I have to vt-switch and kill -9 the debugged process, when vt-switching back to Xorg, fvwm3 resumes normally again.
Here's some debug output from fvwm when it's in this frozen state:
```#0 0x00007f6987003675 in select () at /lib64/libc.so.6
#1 0x00005585156a4bd7 in fvwmSelect (nfds=1024, readfds=0x7ffdc1e0ebf0, writefds=0x7ffdc1e0ec70, exceptfds=0x0, timeout=0x0)
at fvwmsignal.c:208
#2 0x00005585155fb526 in My_XNextEvent (disp=0x55851763d590, event=0x7ffdc1e0ed10) at events.c:4405
#3 0x00005585155fb0d1 in HandleEvents () at events.c:4268
#4 0x0000558515626b04 in main (argc=2, argv=0x7ffdc1e0f1d8) at fvwm3.c:2526
#2 0x00005585155fb526 in My_XNextEvent (disp=0x55851763d590, event=0x7ffdc1e0ed10) at events.c:4405
4405 num_fd = fvwmSelect(
$1 = {tv_sec = 42, tv_usec = 0}
$2 = (struct timeval *) 0x0
$3 = -1
Single stepping until exit from function select,
which has no line number information.
fvwmSelect (nfds=1024, readfds=0x7ffdc1e0ebf0, writefds=0x7ffdc1e0ec70, exceptfds=0x0, timeout=0x0) at fvwmsignal.c:208
208 iRet = select(nfds,
221 canJump = false;
224 return iRet;
225 }
My_XNextEvent (disp=0x55851763d590, event=0x7ffdc1e0ed10) at events.c:4407
4407 if (is_waiting_for_scheduled_command)
4413 if (isTerminated)
4417 } while (num_fd < 0);
4419 if (num_fd > 0)
4422 module_list_itr_init(&moditr);
4423 while ( (module = module_list_itr_next(&moditr)) != NULL)
4425 if (FD_ISSET(MOD_READFD(module), &in_fdset))
4432 MOD_WRITEFD(module) >= 0 &&
4431 if (
4433 FD_ISSET(MOD_WRITEFD(module), &out_fdset))
4432 MOD_WRITEFD(module) >= 0 &&
4423 while ( (module = module_list_itr_next(&moditr)) != NULL)
4425 if (FD_ISSET(MOD_READFD(module), &in_fdset))
4432 MOD_WRITEFD(module) >= 0 &&
Continuing.
[Detaching after fork from child process 20022]
... etc (seems to be continuing the normal event loop)
Note that the timeout passed to the select() call is 0 (infinite) because of, what i think is a bug here:
timeout values are set but timeout is never assigned to timeoutP -
But obviously we /are/ returning from the select, so this has nothing to do with the problem -
Clarification - when i say 'freeze' - what i mean is, the WM, nor applications, will respond to keyboard input or mouse input. (no alt-tab, no titlebar-dragging, the currently focused window also won't receive key events) - rendering still works (my little wmcube keeps spinning) - so it's all input events that have gone dead in this scenario.
The text was updated successfully, but these errors were encountered:
When debugging an application, fvwm3 may completely freeze when a breakpoint is triggered while handling an event.
It's kind of difficult for me to come up with a minimal example that triggers this problem, but I've had this happen when debugging qt applications in qt creator, but also SDL applications with regular gdb. Whenever a breakpoint triggers somewhere in my gui event loop, the entire wm will freeze up. And it's not rare, unfortunately - it's common enough to be very annoying.
When this happens, I have to vt-switch and kill -9 the debugged process, when vt-switching back to Xorg, fvwm3 resumes normally again.
Here's some debug output from fvwm when it's in this frozen state:
... etc (seems to be continuing the normal event loop)
Note that the timeout passed to the select() call is 0 (infinite) because of, what i think is a bug here:
timeout values are set but timeout is never assigned to timeoutP -
But obviously we /are/ returning from the select, so this has nothing to do with the problem -
Clarification - when i say 'freeze' - what i mean is, the WM, nor applications, will respond to keyboard input or mouse input. (no alt-tab, no titlebar-dragging, the currently focused window also won't receive key events) - rendering still works (my little wmcube keeps spinning) - so it's all input events that have gone dead in this scenario.
The text was updated successfully, but these errors were encountered: