public inbox for dwz@sourceware.org
 help / color / mirror / Atom feed
* Buildbot failure in Wildebeest Builder on whole buildset
@ 2021-03-25  8:41 buildbot
  2021-03-25  8:50 ` Fwd: " Tom de Vries
  0 siblings, 1 reply; 5+ messages in thread
From: buildbot @ 2021-03-25  8:41 UTC (permalink / raw)
  To: dwz

The Buildbot has detected a failed build on builder whole buildset while building dwz.
Full details are available at:
    https://builder.wildebeest.org/buildbot/#builders/23/builds/311

Buildbot URL: https://builder.wildebeest.org/buildbot/

Worker for this Build: debian-amd64

Build Reason: <unknown>
Blamelist: Tom de Vries <tdevries@suse.de>

BUILD FAILED: failed test (failure)

Sincerely,
 -The Buildbot


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Fwd: Buildbot failure in Wildebeest Builder on whole buildset
  2021-03-25  8:41 Buildbot failure in Wildebeest Builder on whole buildset buildbot
@ 2021-03-25  8:50 ` Tom de Vries
  2021-03-25 10:41   ` Mark Wielaard
  0 siblings, 1 reply; 5+ messages in thread
From: Tom de Vries @ 2021-03-25  8:50 UTC (permalink / raw)
  To: Mark Wielaard, dwz

Hi Mark,

I've just committed patch "Move hardlink handling out of dwz function"
and there's this buildbot failure.

Is there something easy that you can do to find out if this is a fluke
or not, f.i. retry the build for that bot?

Thanks,
- Tom


-------- Forwarded Message --------
Subject: Buildbot failure in Wildebeest Builder on whole buildset
Date: Thu, 25 Mar 2021 08:41:56 +0000
From: buildbot@builder.wildebeest.org
To: dwz@sourceware.org

The Buildbot has detected a failed build on builder whole buildset while
building dwz.
Full details are available at:
    https://builder.wildebeest.org/buildbot/#builders/23/builds/311

Buildbot URL: https://builder.wildebeest.org/buildbot/

Worker for this Build: debian-amd64

Build Reason: <unknown>
Blamelist: Tom de Vries <tdevries@suse.de>

BUILD FAILED: failed test (failure)

Sincerely,
 -The Buildbot


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Fwd: Buildbot failure in Wildebeest Builder on whole buildset
  2021-03-25  8:50 ` Fwd: " Tom de Vries
@ 2021-03-25 10:41   ` Mark Wielaard
  2021-03-25 10:49     ` Mark Wielaard
  0 siblings, 1 reply; 5+ messages in thread
From: Mark Wielaard @ 2021-03-25 10:41 UTC (permalink / raw)
  To: Tom de Vries, dwz

Hi Tom,

On Thu, 2021-03-25 at 09:50 +0100, Tom de Vries wrote:
> I've just committed patch "Move hardlink handling out of dwz
> function"
> and there's this buildbot failure.
> 
> Is there something easy that you can do to find out if this is a
> fluke
> or not, f.i. retry the build for that bot?

I logged into the buildbot worker and did a dwz build myself.
make check does produce 32 unexpected failures.
Removing the last commit makes everything pass.
Adding the commit again produces the failures again.
It isn't a fluke.

The problem is simply that:
cp hello 1
dwz 1

Makes dwz produce an exit code of 1 which seems to be interpreted as
child process exited abnormally in a make check run.

running under valgrind --track-origins=yes gives:

==31313== Conditional jump or move depends on uninitialised value(s)
==31313==    at 0x127974: dwz (dwz.c:15287)
==31313==    by 0x10BB7C: dwz_with_low_mem (dwz.c:16227)
==31313==    by 0x10BB7C: dwz_one_file (dwz.c:16253)
==31313==    by 0x10BB7C: main (dwz.c:16532)
==31313==  Uninitialised value was created by a stack allocation
==31313==    at 0x10B59B: main (dwz.c:16513)

I haven't tracked down what res->res precisely depends on that doesn't
have a defined value.

Cheers,

Mark

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Fwd: Buildbot failure in Wildebeest Builder on whole buildset
  2021-03-25 10:41   ` Mark Wielaard
@ 2021-03-25 10:49     ` Mark Wielaard
  2021-03-25 14:01       ` Tom de Vries
  0 siblings, 1 reply; 5+ messages in thread
From: Mark Wielaard @ 2021-03-25 10:49 UTC (permalink / raw)
  To: Tom de Vries, dwz

Hi Tom,

On Thu, 2021-03-25 at 11:41 +0100, Mark Wielaard wrote:
> On Thu, 2021-03-25 at 09:50 +0100, Tom de Vries wrote:
> > I've just committed patch "Move hardlink handling out of dwz
> > function"
> > and there's this buildbot failure.
> > 
> > Is there something easy that you can do to find out if this is a
> > fluke
> > or not, f.i. retry the build for that bot?
> 
> I logged into the buildbot worker and did a dwz build myself.
> make check does produce 32 unexpected failures.
> Removing the last commit makes everything pass.
> Adding the commit again produces the failures again.
> It isn't a fluke.
> 
> The problem is simply that:
> cp hello 1
> dwz 1
> 
> Makes dwz produce an exit code of 1 which seems to be interpreted as
> child process exited abnormally in a make check run.
> 
> running under valgrind --track-origins=yes gives:
> 
> ==31313== Conditional jump or move depends on uninitialised value(s)
> ==31313==    at 0x127974: dwz (dwz.c:15287)
> ==31313==    by 0x10BB7C: dwz_with_low_mem (dwz.c:16227)
> ==31313==    by 0x10BB7C: dwz_one_file (dwz.c:16253)
> ==31313==    by 0x10BB7C: main (dwz.c:16532)
> ==31313==  Uninitialised value was created by a stack allocation
> ==31313==    at 0x10B59B: main (dwz.c:16513)
> 
> I haven't tracked down what res->res precisely depends on that
> doesn't
> have a defined value.

Note that dwz_one_file was inlined into main, causing valgrind to
pinpoint the wrong frame. Without inlining we get:

==2502== Conditional jump or move depends on uninitialised value(s)
==2502==    at 0x13CF4F: dwz (dwz.c:15287)
==2502==    by 0x13FE3A: dwz_with_low_mem (dwz.c:16227)
==2502==    by 0x13FEAE: dwz_one_file (dwz.c:16253)
==2502==    by 0x140B59: main (dwz.c:16532)
==2502==  Uninitialised value was created by a stack allocation
==2502==    at 0x13FE7F: dwz_one_file (dwz.c:16245)

And indeed we see:

static int
dwz_one_file (const char *file, const char *outfile)
{
  struct file_result res;

  if (stats_p)
    init_stats (file);

  res.die_count = 0;

  return dwz_with_low_mem (file, outfile, &res, NULL);
}

Defines and passes down res, but only initializes the die_count field.

Then in dwz_with_low_mem we simply pass that res to dwz:

  ret = (low_mem_die_limit == 0
         ? 2
         : dwz (file, outfile, res));

And in dwz the first thing we do is:

  if (res->res == -1)
    return 1;

But res->res was never given a value and so could be anything.

Cheers,

Mark

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Fwd: Buildbot failure in Wildebeest Builder on whole buildset
  2021-03-25 10:49     ` Mark Wielaard
@ 2021-03-25 14:01       ` Tom de Vries
  0 siblings, 0 replies; 5+ messages in thread
From: Tom de Vries @ 2021-03-25 14:01 UTC (permalink / raw)
  To: Mark Wielaard, dwz

On 3/25/21 11:49 AM, Mark Wielaard wrote:
> Hi Tom,
> 
> On Thu, 2021-03-25 at 11:41 +0100, Mark Wielaard wrote:
>> On Thu, 2021-03-25 at 09:50 +0100, Tom de Vries wrote:
>>> I've just committed patch "Move hardlink handling out of dwz
>>> function"
>>> and there's this buildbot failure.
>>>
>>> Is there something easy that you can do to find out if this is a
>>> fluke
>>> or not, f.i. retry the build for that bot?
>>
>> I logged into the buildbot worker and did a dwz build myself.
>> make check does produce 32 unexpected failures.
>> Removing the last commit makes everything pass.
>> Adding the commit again produces the failures again.
>> It isn't a fluke.
>>
>> The problem is simply that:
>> cp hello 1
>> dwz 1
>>
>> Makes dwz produce an exit code of 1 which seems to be interpreted as
>> child process exited abnormally in a make check run.
>>
>> running under valgrind --track-origins=yes gives:
>>
>> ==31313== Conditional jump or move depends on uninitialised value(s)
>> ==31313==    at 0x127974: dwz (dwz.c:15287)
>> ==31313==    by 0x10BB7C: dwz_with_low_mem (dwz.c:16227)
>> ==31313==    by 0x10BB7C: dwz_one_file (dwz.c:16253)
>> ==31313==    by 0x10BB7C: main (dwz.c:16532)
>> ==31313==  Uninitialised value was created by a stack allocation
>> ==31313==    at 0x10B59B: main (dwz.c:16513)
>>
>> I haven't tracked down what res->res precisely depends on that
>> doesn't
>> have a defined value.
> 
> Note that dwz_one_file was inlined into main, causing valgrind to
> pinpoint the wrong frame. Without inlining we get:
> 
> ==2502== Conditional jump or move depends on uninitialised value(s)
> ==2502==    at 0x13CF4F: dwz (dwz.c:15287)
> ==2502==    by 0x13FE3A: dwz_with_low_mem (dwz.c:16227)
> ==2502==    by 0x13FEAE: dwz_one_file (dwz.c:16253)
> ==2502==    by 0x140B59: main (dwz.c:16532)
> ==2502==  Uninitialised value was created by a stack allocation
> ==2502==    at 0x13FE7F: dwz_one_file (dwz.c:16245)
> 
> And indeed we see:
> 
> static int
> dwz_one_file (const char *file, const char *outfile)
> {
>   struct file_result res;
> 
>   if (stats_p)
>     init_stats (file);
> 
>   res.die_count = 0;
> 
>   return dwz_with_low_mem (file, outfile, &res, NULL);
> }
> 
> Defines and passes down res, but only initializes the die_count field.
> 
> Then in dwz_with_low_mem we simply pass that res to dwz:
> 
>   ret = (low_mem_die_limit == 0
>          ? 2
>          : dwz (file, outfile, res));
> 
> And in dwz the first thing we do is:
> 
>   if (res->res == -1)
>     return 1;
> 
> But res->res was never given a value and so could be anything.
> 

Hi Mark,

thanks for helping out with this.

I've fixed this now, and verified that the buildbot is back to all-green.

After seeing your analysis, I realized I had tried -fsanitize=address
but not valgrind, and indeed using valgrind I managed to reproduce the
problem myself.

I've submitted a patch proposing a check-valgrind target in the
Makefile, to remind me to try this next time.

Thanks,
- Tom

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2021-03-25 14:01 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-25  8:41 Buildbot failure in Wildebeest Builder on whole buildset buildbot
2021-03-25  8:50 ` Fwd: " Tom de Vries
2021-03-25 10:41   ` Mark Wielaard
2021-03-25 10:49     ` Mark Wielaard
2021-03-25 14:01       ` Tom de Vries

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).