Re: GDB and thread
Am 29.12.2019 um 13:58 schrieb Jon Turney: On 28/12/2019 21:27, Marco Atzeri wrote: Hi, I am trying to debug the libuv test failures, but it seems I am not able to convince GDB on stopping just before the failure. I think that the problem here is that the libuv test runner forks() to run each test in a subprocess. I don't think 'set follow-fork-mode child' works in Cygwin gdb (unfortunately). I'm not sure if it's even possible to implement... thanks for the hint, it seems the right one. https://sourceware.org/gdb/onlinedocs/gdb/Forks.html I doubt the sleep suggestion will work, but at least now I know where is the issue. I suspect a nice insertion of printf in the code will be easier for the debugging scope. Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: GDB and thread
On 28/12/2019 21:27, Marco Atzeri wrote: Hi, I am trying to debug the libuv test failures, but it seems I am not able to convince GDB on stopping just before the failure. I think that the problem here is that the libuv test runner forks() to run each test in a subprocess. I don't think 'set follow-fork-mode child' works in Cygwin gdb (unfortunately). I'm not sure if it's even possible to implement... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: GDB and thread
Am 29.12.2019 um 05:38 schrieb Brian Inglis: On 2019-12-28 15:28, Marco Atzeri wrote: Am 28.12.2019 um 23:03 schrieb Ken Brown: On 12/28/2019 4:27 PM, Marco Atzeri wrote: I am trying to debug the libuv test failures, but it seems I am not able to convince GDB on stopping just before the failure. Is "thread apply all" working on Cygwin ? The fact that produces no output in comparison to a normal break command is a bit strange (gdb) break test-dlerror.c:34 Breakpoint 1 at 0x10040b0b0: file /pub/devel/libuv/libuv-1.34.0/test/test-dlerro r.c, line 34. (gdb) thread apply all break test-dlerror.c:34 Might this be related to optimization? That could change the order in which lines of code are executed. Have you tried building without optimization? Already thought, but it is built with -ggdb -O0 Recommended to use at least -Og nowadays for better debugging: $ info gcc inv debug "With no '-O' option at all, some compiler passes that collect information useful for debugging do not run at all, so that '-Og' may result in a better debugging experience." Thanks for the info unfortunately there is no difference. It is like the debugger is unable to see the breakpoints when running in this threaded code. Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: GDB and thread
On 2019-12-28 15:28, Marco Atzeri wrote: > Am 28.12.2019 um 23:03 schrieb Ken Brown: >> On 12/28/2019 4:27 PM, Marco Atzeri wrote: >>> I am trying to debug the libuv test failures, >>> but it seems I am not able to convince GDB on stopping >>> just before the failure. >>> >>> Is "thread apply all" working on Cygwin ? >>> The fact that produces no output in comparison to >>> a normal break command is a bit strange >>> >>> (gdb) break test-dlerror.c:34 >>> Breakpoint 1 at 0x10040b0b0: file >>> /pub/devel/libuv/libuv-1.34.0/test/test-dlerro >>> r.c, line 34. >>> (gdb) thread apply all break test-dlerror.c:34 >> >> Others know this better than I do, but I seem to recall that a break command >> automatically applies to all threads. In other words, "thread apply all" is >> redundant. > > It seems to ignore any break for what I see. > thread apply all was a tentative after simple break was ineffective >>> Any hint will be appreciated >> >> Might this be related to optimization? That could change the order in which >> lines of code are executed. Have you tried building without optimization? > > Already thought, but it is built with -ggdb -O0 Recommended to use at least -Og nowadays for better debugging: $ info gcc inv debug "With no '-O' option at all, some compiler passes that collect information useful for debugging do not run at all, so that '-Og' may result in a better debugging experience." -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: GDB and thread
Am 28.12.2019 um 23:03 schrieb Ken Brown: On 12/28/2019 4:27 PM, Marco Atzeri wrote: Hi, I am trying to debug the libuv test failures, but it seems I am not able to convince GDB on stopping just before the failure. Is "thread apply all" working on Cygwin ? The fact that produces no output in comparison to a normal break command is a bit strange (gdb) break test-dlerror.c:34 Breakpoint 1 at 0x10040b0b0: file /pub/devel/libuv/libuv-1.34.0/test/test-dlerro r.c, line 34. (gdb) thread apply all break test-dlerror.c:34 Others know this better than I do, but I seem to recall that a break command automatically applies to all threads. In other words, "thread apply all" is redundant. It seems to ignore any break for what I see. thread apply all was a tentative after simple break was ineffective (gdb) run dlerror Starting program: /cygdrive/d/cyg_pub/devel/libuv/libuv-1.34.0-build/test/.libs/ run-tests.exe dlerror [New Thread 139176.0x231a0] [New Thread 139176.0x231c8] [New Thread 139176.0x21a0c] [New Thread 139176.0x2332c] [New Thread 139176.0x230b0] [New Thread 139176.0x231cc] [New Thread 139176.0x23028] [New Thread 139176.0x23214] [Thread 139176.0x23028 exited with code 0] not ok 1 - dlerror # exit code 134 # Output from process `dlerror`: # Assertion failed in /pub/devel/libuv/libuv-1.34.0/test/test-dlerror.c on line 45: strstr(msg, path) != NULL [Thread 139176.0x231c8 exited with code 134] [Thread 139176.0x230b0 exited with code 134] [Thread 139176.0x2332c exited with code 134] [Thread 139176.0x23214 exited with code 134] [Thread 139176.0x21a0c exited with code 134] [Inferior 1 (process 139176) exited with code 0206] (gdb) Any hint will be appreciated Might this be related to optimization? That could change the order in which lines of code are executed. Have you tried building without optimization? Already thought, but it is built with -ggdb -O0 Ken Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: GDB and thread
On 12/28/2019 4:27 PM, Marco Atzeri wrote: > Hi, > I am trying to debug the libuv test failures, > but it seems I am not able to convince GDB on stopping > just before the failure. > > Is "thread apply all" working on Cygwin ? > The fact that produces no output in comparison to > a normal break command is a bit strange > > (gdb) break test-dlerror.c:34 > Breakpoint 1 at 0x10040b0b0: file > /pub/devel/libuv/libuv-1.34.0/test/test-dlerro > r.c, line 34. > (gdb) thread apply all break test-dlerror.c:34 Others know this better than I do, but I seem to recall that a break command automatically applies to all threads. In other words, "thread apply all" is redundant. > (gdb) run dlerror > Starting program: > /cygdrive/d/cyg_pub/devel/libuv/libuv-1.34.0-build/test/.libs/ > run-tests.exe dlerror > [New Thread 139176.0x231a0] > [New Thread 139176.0x231c8] > [New Thread 139176.0x21a0c] > [New Thread 139176.0x2332c] > [New Thread 139176.0x230b0] > [New Thread 139176.0x231cc] > [New Thread 139176.0x23028] > [New Thread 139176.0x23214] > [Thread 139176.0x23028 exited with code 0] > not ok 1 - dlerror > # exit code 134 > # Output from process `dlerror`: > # Assertion failed in /pub/devel/libuv/libuv-1.34.0/test/test-dlerror.c on > line > 45: strstr(msg, path) != NULL > [Thread 139176.0x231c8 exited with code 134] > [Thread 139176.0x230b0 exited with code 134] > [Thread 139176.0x2332c exited with code 134] > [Thread 139176.0x23214 exited with code 134] > [Thread 139176.0x21a0c exited with code 134] > [Inferior 1 (process 139176) exited with code 0206] > (gdb) > > > Any hint will be appreciated Might this be related to optimization? That could change the order in which lines of code are executed. Have you tried building without optimization? Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
