GDB and thread

GDB and thread

[Marco Atzeri]

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

(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
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

[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.

> (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

Re: GDB and thread

[Marco Atzeri]

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

[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
>>
>> 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

[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
>>
>> 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

[Marco Atzeri]

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

[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...


--
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

[Marco Atzeri]

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