X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=izNB2STjSqKGL7Sp
	IjIWo3pH7SNLSf/iPhSfzeGEJG7mBpLAQKxN8iu4SlZhXO6hf2LFUecltgcmH0m5
	ke37U8QSCA2g7xp2dx1RKJnd8EW+unFwc4Zi+8fGa0JOgtrDKYik6wxA3GZrCm8j
	mDQiAgWGSWOqONa0RRtCE1jtols=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=nvu7tdJcCYCb353bzpZiVO
	fV6ck=; b=CfODjl3STkuZ632my6y3+SSuzVYFdhhE9tYd8Vx/pcgbJOuDQROvcN
	OszWT6rK1CiVHO9Ve3gKvjMYn90/bH7X4kd+kn6+oitfShwiKiH0WwAqmW847AgD
	s+gepQWHnA4EdO3NwQqnY1Y7heE92H+sQzbWhFVAnwsk3v5zYeg8M=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Spam-SWARE-Status:	No, score=-0.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_WEB,SPF_PASS autolearn=no version=3.3.1 spammy=
X-HELO:	mail-wm1-f50.google.com
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=vP+MRSkl7RbrwrIceKKwCyeqRGP6N7WuHg4GDGFPeAw=; b=X6A2hWVe619ESytdr+0B3/joXFZncIeYmoQtFwspney1Mey07actcBnnzQ6ZO9abA8 cd3tDUtM28YNWm+HOkeiOdjmmbWEp6q1AwpZwv+nJvfjVVCsFPIjnfUCTZy+VnY/cDvJ 2Rvdv4DsxWcR12TQq10ohlKS/MVcVMMdrE4ygB4ntNhOc70q3CFi0MojNHLB+PB6e6TG zQ/PRpH4r0O13zxlqy5G9E3lb3vrnR3f0xDD0z6tJvHvopCXQEDqGzgLw7Pq/Mb8bPSY hGGet/WDQXReBI61Xqon/Ypx93BmcD0fnkxj78Sjm8hJ8/dj1WNsoVmBD0ISkzcbnGp8 gSGg==
Subject:	Re: GDB and thread
To:	cygwin AT cygwin DOT com
References:	<b0d8c3b7-6ebd-3fce-f1b6-4542fb5a37c7 AT gmail DOT com> <cc4cf832-e661-dfc1-853a-c1b9ab71bca9 AT cornell DOT edu>
From:	Marco Atzeri <marco DOT atzeri AT gmail DOT com>
Message-ID:	<d24dfbbd-5883-4675-1889-9428142aca04@gmail.com>
Date:	Sat, 28 Dec 2019 23:28:33 +0100
User-Agent:	Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1
MIME-Version:	1.0
In-Reply-To:	<cc4cf832-e661-dfc1-853a-c1b9ab71bca9@cornell.edu>
X-IsSubscribed:	yes

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

- Raw text -