[gem5-dev] Re: Build failed in Jenkins: nightly #27

2021-11-06 Thread Jason Lowe-Power via gem5-dev 
OK! Thinking that it might be a python issue, I tried updating pybind and
the segfault goes away for me in at least some cases. However, it depends
on the different fixes that I've applied which are still on gerrit. Maybe
taken all together it works? It's hard to tell.

It worries me that we never tracked it down, but this seems like a
reasonable stop-gap. Let's try to push this in and see if that makes
Jenkins happier.

https://gem5-review.googlesource.com/c/public/gem5/+/52523

Cheers,
Jason

On Fri, Nov 5, 2021 at 9:03 PM Gabe Black  wrote:

> +Bobby who's fingerprints I see on the pybind stats interface, and
> +Andreas who has a lot of experience with pybind. I started digging into
> the code myself, but I got confused and stopped.
>
> I think there's some sort of reference counting bug here, where some stats
> related something is getting deleted before it's supposed to, and then
> that's getting referred to at the end of the simulation and exploding.
>
> Gabe
>
> On Fri, Nov 5, 2021 at 8:50 PM Gabe Black  wrote:
>
>> That was run on an older checkout where I had reproduced the segfault
>> before, so here is a newer one with (I think) all of the fixes so far. The
>> stats events in the valgrind log still show up.
>>
>> Gabe
>>
>> On Fri, Nov 5, 2021 at 6:39 PM Gabe Black  wrote:
>>
>>> Here is a log from a valgrind run without any suppressions. I let it run
>>> a little bit and then stopped it so it would finish fairly quickly, but
>>> that still went through the process at the end of printing stats. You can
>>> see a lot of pretty concerning output related to stats, so I think that
>>> might be a fertile area to explore.
>>>
>>> Gabe
>>>
>>> On Fri, Nov 5, 2021 at 5:58 PM Gabe Black  wrote:
>>>
 I had started to hunt these down earlier, to get rid of the warning
 messages that pop up when running the tests. It's a WIP and only in Ruby at
 the moment, so likely not applicable here.

 https://gem5-review.googlesource.com/c/public/gem5/+/52505

 You can look at the change I'd made to the base stats to get an idea
 for how to root them out with the compiler.

 Gabe

 On Fri, Nov 5, 2021 at 5:12 PM Jason Lowe-Power 
 wrote:

> Ah, I found them (what a pain...).
>
> Here's a couple of changeset removing these legacy stats. Maybe this
> will solve the issue. I'm heading out for the day, but I'll check on it
> tomorrow morning.
>
> https://gem5-review.googlesource.com/c/public/gem5/+/52503
> https://gem5-review.googlesource.com/c/public/gem5/+/52504
>
> Cheers,
> Jason
>
> On Fri, Nov 5, 2021 at 4:55 PM Jason Lowe-Power 
> wrote:
>
>> Well, now I got the segfault in a stats++ operator (I can't tell you
>> exactly where as the templates in stats hid all of the useful 
>> information).
>> It happened ~10 cycles before the end of simulation this time.
>>
>> I am thinking it might be a "legacy" stat bug. But, again because of
>> the template magic in stats I can't find the statistic name that is
>> "legacy".
>>
>> Jason
>>
>> On Fri, Nov 5, 2021 at 4:48 PM Gabe Black 
>> wrote:
>>
>>>
>>>
>>> On Fri, Nov 5, 2021 at 11:18 AM Jason Lowe-Power <
>>> ja...@lowepower.com> wrote:
>>>
 Here's what the undefined behavior sanitizer says with these
 patches applied. Also, the backtrace from the core dump is shown.


 build/ARM_clang/base/stats/text.cc:234:13: runtime error: load of
 value 32, which is not a valid value for type 'bool'
 SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
 build/ARM_clang/base/stats/text.cc:234:13 in
 gem5 has encountered a segmentation fault!

>>>
>>> I think this will fix the undefined behavior at least:
>>>
>>> https://gem5-review.googlesource.com/c/public/gem5/+/52483
>>>
>>> The fact that the segfault happens after this point says even more
>>> that this is some sort of cleanup thing, since the undefined behavior is
>>> from when it's printing stats to a text file.
>>>
>>>

 --- BEGIN LIBC BACKTRACE ---
 build/ARM_clang/gem5.opt[0x1c7684a]
 build/ARM_clang/gem5.opt[0x1cc6255]
 /lib/x86_64-linux-gnu/libpthread.so.0(+0x153c0)[0x7feaafd103c0]

 /lib/x86_64-linux-gnu/libtcmalloc.so.4(_ZN8tcmalloc11ThreadCache21ReleaseToCentralCacheEPNS0_8FreeListEji+0x93)[0x7feaaf9b9f83]

 /lib/x86_64-linux-gnu/libtcmalloc.so.4(_ZN8tcmalloc11ThreadCache8ScavengeEv+0x4e)[0x7feaaf9ba2de]
 /lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0x2707e8)[0x7feaaff8e7e8]

 /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyState_ClearModules+0xb5)[0x7feaafead745]

 /lib/x86_64-linux-gnu/libpython3.8.so.1.0(PyImport_Cleanup+0x4f7)[0x7feaafec61c7]

[gem5-dev] Re: Build failed in Jenkins: nightly #27

2021-11-05 Thread Gabe Black via gem5-dev 
+Bobby who's fingerprints I see on the pybind stats interface, and +Andreas
who has a lot of experience with pybind. I started digging into the code
myself, but I got confused and stopped.

I think there's some sort of reference counting bug here, where some stats
related something is getting deleted before it's supposed to, and then
that's getting referred to at the end of the simulation and exploding.

Gabe

On Fri, Nov 5, 2021 at 8:50 PM Gabe Black  wrote:

> That was run on an older checkout where I had reproduced the segfault
> before, so here is a newer one with (I think) all of the fixes so far. The
> stats events in the valgrind log still show up.
>
> Gabe
>
> On Fri, Nov 5, 2021 at 6:39 PM Gabe Black  wrote:
>
>> Here is a log from a valgrind run without any suppressions. I let it run
>> a little bit and then stopped it so it would finish fairly quickly, but
>> that still went through the process at the end of printing stats. You can
>> see a lot of pretty concerning output related to stats, so I think that
>> might be a fertile area to explore.
>>
>> Gabe
>>
>> On Fri, Nov 5, 2021 at 5:58 PM Gabe Black  wrote:
>>
>>> I had started to hunt these down earlier, to get rid of the warning
>>> messages that pop up when running the tests. It's a WIP and only in Ruby at
>>> the moment, so likely not applicable here.
>>>
>>> https://gem5-review.googlesource.com/c/public/gem5/+/52505
>>>
>>> You can look at the change I'd made to the base stats to get an idea for
>>> how to root them out with the compiler.
>>>
>>> Gabe
>>>
>>> On Fri, Nov 5, 2021 at 5:12 PM Jason Lowe-Power 
>>> wrote:
>>>
 Ah, I found them (what a pain...).

 Here's a couple of changeset removing these legacy stats. Maybe this
 will solve the issue. I'm heading out for the day, but I'll check on it
 tomorrow morning.

 https://gem5-review.googlesource.com/c/public/gem5/+/52503
 https://gem5-review.googlesource.com/c/public/gem5/+/52504

 Cheers,
 Jason

 On Fri, Nov 5, 2021 at 4:55 PM Jason Lowe-Power 
 wrote:

> Well, now I got the segfault in a stats++ operator (I can't tell you
> exactly where as the templates in stats hid all of the useful 
> information).
> It happened ~10 cycles before the end of simulation this time.
>
> I am thinking it might be a "legacy" stat bug. But, again because of
> the template magic in stats I can't find the statistic name that is
> "legacy".
>
> Jason
>
> On Fri, Nov 5, 2021 at 4:48 PM Gabe Black 
> wrote:
>
>>
>>
>> On Fri, Nov 5, 2021 at 11:18 AM Jason Lowe-Power 
>> wrote:
>>
>>> Here's what the undefined behavior sanitizer says with these patches
>>> applied. Also, the backtrace from the core dump is shown.
>>>
>>>
>>> build/ARM_clang/base/stats/text.cc:234:13: runtime error: load of
>>> value 32, which is not a valid value for type 'bool'
>>> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
>>> build/ARM_clang/base/stats/text.cc:234:13 in
>>> gem5 has encountered a segmentation fault!
>>>
>>
>> I think this will fix the undefined behavior at least:
>>
>> https://gem5-review.googlesource.com/c/public/gem5/+/52483
>>
>> The fact that the segfault happens after this point says even more
>> that this is some sort of cleanup thing, since the undefined behavior is
>> from when it's printing stats to a text file.
>>
>>
>>>
>>> --- BEGIN LIBC BACKTRACE ---
>>> build/ARM_clang/gem5.opt[0x1c7684a]
>>> build/ARM_clang/gem5.opt[0x1cc6255]
>>> /lib/x86_64-linux-gnu/libpthread.so.0(+0x153c0)[0x7feaafd103c0]
>>>
>>> /lib/x86_64-linux-gnu/libtcmalloc.so.4(_ZN8tcmalloc11ThreadCache21ReleaseToCentralCacheEPNS0_8FreeListEji+0x93)[0x7feaaf9b9f83]
>>>
>>> /lib/x86_64-linux-gnu/libtcmalloc.so.4(_ZN8tcmalloc11ThreadCache8ScavengeEv+0x4e)[0x7feaaf9ba2de]
>>> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0x2707e8)[0x7feaaff8e7e8]
>>>
>>> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyState_ClearModules+0xb5)[0x7feaafead745]
>>>
>>> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(PyImport_Cleanup+0x4f7)[0x7feaafec61c7]
>>>
>>> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(Py_FinalizeEx+0x90)[0x7feaafeb1690]
>>> build/ARM_clang/gem5.opt[0x1cc8a07]
>>>
>>> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x7feaaf28e0b3]
>>> build/ARM_clang/gem5.opt[0x5e078e]
>>> --- END LIBC BACKTRACE ---
>>>
>>
>> Is there some sort of bookkeeping bug in the stats interaction
>> between c++ and python? This is a crash in the heap manager triggered by
>> the python interpreter doing some sort of cleanup. I can imagine this 
>> being
>> a latent bug where something was corrupted earlier and it's just falling
>> over now, but this makes sense for three reasons. First, python stats
>> related problems would likely

[gem5-dev] Re: Build failed in Jenkins: nightly #27

2021-11-05 Thread Gabe Black via gem5-dev 
I had started to hunt these down earlier, to get rid of the warning
messages that pop up when running the tests. It's a WIP and only in Ruby at
the moment, so likely not applicable here.

https://gem5-review.googlesource.com/c/public/gem5/+/52505

You can look at the change I'd made to the base stats to get an idea for
how to root them out with the compiler.

Gabe

On Fri, Nov 5, 2021 at 5:12 PM Jason Lowe-Power  wrote:

> Ah, I found them (what a pain...).
>
> Here's a couple of changeset removing these legacy stats. Maybe this will
> solve the issue. I'm heading out for the day, but I'll check on it tomorrow
> morning.
>
> https://gem5-review.googlesource.com/c/public/gem5/+/52503
> https://gem5-review.googlesource.com/c/public/gem5/+/52504
>
> Cheers,
> Jason
>
> On Fri, Nov 5, 2021 at 4:55 PM Jason Lowe-Power 
> wrote:
>
>> Well, now I got the segfault in a stats++ operator (I can't tell you
>> exactly where as the templates in stats hid all of the useful information).
>> It happened ~10 cycles before the end of simulation this time.
>>
>> I am thinking it might be a "legacy" stat bug. But, again because of the
>> template magic in stats I can't find the statistic name that is "legacy".
>>
>> Jason
>>
>> On Fri, Nov 5, 2021 at 4:48 PM Gabe Black  wrote:
>>
>>>
>>>
>>> On Fri, Nov 5, 2021 at 11:18 AM Jason Lowe-Power 
>>> wrote:
>>>
 Here's what the undefined behavior sanitizer says with these patches
 applied. Also, the backtrace from the core dump is shown.


 build/ARM_clang/base/stats/text.cc:234:13: runtime error: load of value
 32, which is not a valid value for type 'bool'
 SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
 build/ARM_clang/base/stats/text.cc:234:13 in
 gem5 has encountered a segmentation fault!

>>>
>>> I think this will fix the undefined behavior at least:
>>>
>>> https://gem5-review.googlesource.com/c/public/gem5/+/52483
>>>
>>> The fact that the segfault happens after this point says even more that
>>> this is some sort of cleanup thing, since the undefined behavior is from
>>> when it's printing stats to a text file.
>>>
>>>

 --- BEGIN LIBC BACKTRACE ---
 build/ARM_clang/gem5.opt[0x1c7684a]
 build/ARM_clang/gem5.opt[0x1cc6255]
 /lib/x86_64-linux-gnu/libpthread.so.0(+0x153c0)[0x7feaafd103c0]

 /lib/x86_64-linux-gnu/libtcmalloc.so.4(_ZN8tcmalloc11ThreadCache21ReleaseToCentralCacheEPNS0_8FreeListEji+0x93)[0x7feaaf9b9f83]

 /lib/x86_64-linux-gnu/libtcmalloc.so.4(_ZN8tcmalloc11ThreadCache8ScavengeEv+0x4e)[0x7feaaf9ba2de]
 /lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0x2707e8)[0x7feaaff8e7e8]

 /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyState_ClearModules+0xb5)[0x7feaafead745]

 /lib/x86_64-linux-gnu/libpython3.8.so.1.0(PyImport_Cleanup+0x4f7)[0x7feaafec61c7]

 /lib/x86_64-linux-gnu/libpython3.8.so.1.0(Py_FinalizeEx+0x90)[0x7feaafeb1690]
 build/ARM_clang/gem5.opt[0x1cc8a07]
 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x7feaaf28e0b3]
 build/ARM_clang/gem5.opt[0x5e078e]
 --- END LIBC BACKTRACE ---

>>>
>>> Is there some sort of bookkeeping bug in the stats interaction between
>>> c++ and python? This is a crash in the heap manager triggered by the python
>>> interpreter doing some sort of cleanup. I can imagine this being a latent
>>> bug where something was corrupted earlier and it's just falling over now,
>>> but this makes sense for three reasons. First, python stats related
>>> problems would likely show up at the end when the stats are printed out
>>> which is done partially through python. Second, python's reference counting
>>> stuff would be easy to make a mistake with since it's complicated and
>>> sometimes has to be handled manually. Third, when running valgrind, I
>>> suppressed errors in the python library which would hide any bad behavior
>>> right before the segfault.
>>>
>>>
>>>

 Cheers,
 Jason

 On Fri, Nov 5, 2021 at 7:28 AM Gabe Black  wrote:

> Can you try this pair of changes?
>
> https://gem5-review.googlesource.com/c/public/gem5/+/52485/1
>
> I think this should at least fix the undefined behavior, but when I
> tried to test it it took an hour and a half to unsuccessfully compile with
> the sanitizers for build/ARM so I gave up.
>
> I'm hopeful this could also fix the segfault?
>
> Gabe
>
> On Thu, Nov 4, 2021 at 4:18 PM Gabe Black 
> wrote:
>
>> Oh, yes, that does look very suspicious. I'll have to take a closer
>> look at that!
>>
>> Gabe
>>
>> On Thu, Nov 4, 2021 at 3:02 PM Jason Lowe-Power 
>> wrote:
>>
>>> Glad you asked! I didn't look closely enough at the output.
>>>
>>> Here's an error that looks suspicious (The whole file is attached.)
>>>
>>> build/ARM_clang/cpu/o3/dyn_inst.hh:252:29: runtime error:
>>> constructor call on misaligned address 0x1c1ed9ac for type

[gem5-dev] Re: Build failed in Jenkins: nightly #27

2021-11-05 Thread Jason Lowe-Power via gem5-dev 
Ah, I found them (what a pain...).

Here's a couple of changeset removing these legacy stats. Maybe this will
solve the issue. I'm heading out for the day, but I'll check on it tomorrow
morning.

https://gem5-review.googlesource.com/c/public/gem5/+/52503
https://gem5-review.googlesource.com/c/public/gem5/+/52504

Cheers,
Jason

On Fri, Nov 5, 2021 at 4:55 PM Jason Lowe-Power  wrote:

> Well, now I got the segfault in a stats++ operator (I can't tell you
> exactly where as the templates in stats hid all of the useful information).
> It happened ~10 cycles before the end of simulation this time.
>
> I am thinking it might be a "legacy" stat bug. But, again because of the
> template magic in stats I can't find the statistic name that is "legacy".
>
> Jason
>
> On Fri, Nov 5, 2021 at 4:48 PM Gabe Black  wrote:
>
>>
>>
>> On Fri, Nov 5, 2021 at 11:18 AM Jason Lowe-Power 
>> wrote:
>>
>>> Here's what the undefined behavior sanitizer says with these patches
>>> applied. Also, the backtrace from the core dump is shown.
>>>
>>>
>>> build/ARM_clang/base/stats/text.cc:234:13: runtime error: load of value
>>> 32, which is not a valid value for type 'bool'
>>> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
>>> build/ARM_clang/base/stats/text.cc:234:13 in
>>> gem5 has encountered a segmentation fault!
>>>
>>
>> I think this will fix the undefined behavior at least:
>>
>> https://gem5-review.googlesource.com/c/public/gem5/+/52483
>>
>> The fact that the segfault happens after this point says even more that
>> this is some sort of cleanup thing, since the undefined behavior is from
>> when it's printing stats to a text file.
>>
>>
>>>
>>> --- BEGIN LIBC BACKTRACE ---
>>> build/ARM_clang/gem5.opt[0x1c7684a]
>>> build/ARM_clang/gem5.opt[0x1cc6255]
>>> /lib/x86_64-linux-gnu/libpthread.so.0(+0x153c0)[0x7feaafd103c0]
>>>
>>> /lib/x86_64-linux-gnu/libtcmalloc.so.4(_ZN8tcmalloc11ThreadCache21ReleaseToCentralCacheEPNS0_8FreeListEji+0x93)[0x7feaaf9b9f83]
>>>
>>> /lib/x86_64-linux-gnu/libtcmalloc.so.4(_ZN8tcmalloc11ThreadCache8ScavengeEv+0x4e)[0x7feaaf9ba2de]
>>> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0x2707e8)[0x7feaaff8e7e8]
>>>
>>> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyState_ClearModules+0xb5)[0x7feaafead745]
>>>
>>> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(PyImport_Cleanup+0x4f7)[0x7feaafec61c7]
>>>
>>> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(Py_FinalizeEx+0x90)[0x7feaafeb1690]
>>> build/ARM_clang/gem5.opt[0x1cc8a07]
>>> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x7feaaf28e0b3]
>>> build/ARM_clang/gem5.opt[0x5e078e]
>>> --- END LIBC BACKTRACE ---
>>>
>>
>> Is there some sort of bookkeeping bug in the stats interaction between
>> c++ and python? This is a crash in the heap manager triggered by the python
>> interpreter doing some sort of cleanup. I can imagine this being a latent
>> bug where something was corrupted earlier and it's just falling over now,
>> but this makes sense for three reasons. First, python stats related
>> problems would likely show up at the end when the stats are printed out
>> which is done partially through python. Second, python's reference counting
>> stuff would be easy to make a mistake with since it's complicated and
>> sometimes has to be handled manually. Third, when running valgrind, I
>> suppressed errors in the python library which would hide any bad behavior
>> right before the segfault.
>>
>>
>>
>>>
>>> Cheers,
>>> Jason
>>>
>>> On Fri, Nov 5, 2021 at 7:28 AM Gabe Black  wrote:
>>>
 Can you try this pair of changes?

 https://gem5-review.googlesource.com/c/public/gem5/+/52485/1

 I think this should at least fix the undefined behavior, but when I
 tried to test it it took an hour and a half to unsuccessfully compile with
 the sanitizers for build/ARM so I gave up.

 I'm hopeful this could also fix the segfault?

 Gabe

 On Thu, Nov 4, 2021 at 4:18 PM Gabe Black  wrote:

> Oh, yes, that does look very suspicious. I'll have to take a closer
> look at that!
>
> Gabe
>
> On Thu, Nov 4, 2021 at 3:02 PM Jason Lowe-Power 
> wrote:
>
>> Glad you asked! I didn't look closely enough at the output.
>>
>> Here's an error that looks suspicious (The whole file is attached.)
>>
>> build/ARM_clang/cpu/o3/dyn_inst.hh:252:29: runtime error: constructor
>> call on misaligned address 0x1c1ed9ac for type 'gem5::PhysRegId *',
>> which requires 8 byte alignment
>> 0x1c1ed9ac: note: pointer points here
>>   00 00 00 00 00 00 00 00  50 d9 1e 1c 00 00 00 00  70 8d 20 1c 00 00
>> 00 00  40 58 1e 1c 00 00 00 00
>>   ^
>> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
>> build/ARM_clang/cpu/o3/dyn_inst.hh:252:29 in
>> build/ARM_clang/cpu/o3/dyn_inst.hh:335:13: runtime error: store to
>> misaligned address 0x1c1ed9bc for type 'gem5::PhysRegIdPtr' (aka
>> 'gem5::PhysRegId *'), which requires 8 byte

[gem5-dev] Re: Build failed in Jenkins: nightly #27

2021-11-05 Thread Jason Lowe-Power via gem5-dev 
Well, now I got the segfault in a stats++ operator (I can't tell you
exactly where as the templates in stats hid all of the useful information).
It happened ~10 cycles before the end of simulation this time.

I am thinking it might be a "legacy" stat bug. But, again because of the
template magic in stats I can't find the statistic name that is "legacy".

Jason

On Fri, Nov 5, 2021 at 4:48 PM Gabe Black  wrote:

>
>
> On Fri, Nov 5, 2021 at 11:18 AM Jason Lowe-Power 
> wrote:
>
>> Here's what the undefined behavior sanitizer says with these patches
>> applied. Also, the backtrace from the core dump is shown.
>>
>>
>> build/ARM_clang/base/stats/text.cc:234:13: runtime error: load of value
>> 32, which is not a valid value for type 'bool'
>> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
>> build/ARM_clang/base/stats/text.cc:234:13 in
>> gem5 has encountered a segmentation fault!
>>
>
> I think this will fix the undefined behavior at least:
>
> https://gem5-review.googlesource.com/c/public/gem5/+/52483
>
> The fact that the segfault happens after this point says even more that
> this is some sort of cleanup thing, since the undefined behavior is from
> when it's printing stats to a text file.
>
>
>>
>> --- BEGIN LIBC BACKTRACE ---
>> build/ARM_clang/gem5.opt[0x1c7684a]
>> build/ARM_clang/gem5.opt[0x1cc6255]
>> /lib/x86_64-linux-gnu/libpthread.so.0(+0x153c0)[0x7feaafd103c0]
>>
>> /lib/x86_64-linux-gnu/libtcmalloc.so.4(_ZN8tcmalloc11ThreadCache21ReleaseToCentralCacheEPNS0_8FreeListEji+0x93)[0x7feaaf9b9f83]
>>
>> /lib/x86_64-linux-gnu/libtcmalloc.so.4(_ZN8tcmalloc11ThreadCache8ScavengeEv+0x4e)[0x7feaaf9ba2de]
>> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0x2707e8)[0x7feaaff8e7e8]
>>
>> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyState_ClearModules+0xb5)[0x7feaafead745]
>>
>> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(PyImport_Cleanup+0x4f7)[0x7feaafec61c7]
>>
>> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(Py_FinalizeEx+0x90)[0x7feaafeb1690]
>> build/ARM_clang/gem5.opt[0x1cc8a07]
>> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x7feaaf28e0b3]
>> build/ARM_clang/gem5.opt[0x5e078e]
>> --- END LIBC BACKTRACE ---
>>
>
> Is there some sort of bookkeeping bug in the stats interaction between c++
> and python? This is a crash in the heap manager triggered by the python
> interpreter doing some sort of cleanup. I can imagine this being a latent
> bug where something was corrupted earlier and it's just falling over now,
> but this makes sense for three reasons. First, python stats related
> problems would likely show up at the end when the stats are printed out
> which is done partially through python. Second, python's reference counting
> stuff would be easy to make a mistake with since it's complicated and
> sometimes has to be handled manually. Third, when running valgrind, I
> suppressed errors in the python library which would hide any bad behavior
> right before the segfault.
>
>
>
>>
>> Cheers,
>> Jason
>>
>> On Fri, Nov 5, 2021 at 7:28 AM Gabe Black  wrote:
>>
>>> Can you try this pair of changes?
>>>
>>> https://gem5-review.googlesource.com/c/public/gem5/+/52485/1
>>>
>>> I think this should at least fix the undefined behavior, but when I
>>> tried to test it it took an hour and a half to unsuccessfully compile with
>>> the sanitizers for build/ARM so I gave up.
>>>
>>> I'm hopeful this could also fix the segfault?
>>>
>>> Gabe
>>>
>>> On Thu, Nov 4, 2021 at 4:18 PM Gabe Black  wrote:
>>>
 Oh, yes, that does look very suspicious. I'll have to take a closer
 look at that!

 Gabe

 On Thu, Nov 4, 2021 at 3:02 PM Jason Lowe-Power 
 wrote:

> Glad you asked! I didn't look closely enough at the output.
>
> Here's an error that looks suspicious (The whole file is attached.)
>
> build/ARM_clang/cpu/o3/dyn_inst.hh:252:29: runtime error: constructor
> call on misaligned address 0x1c1ed9ac for type 'gem5::PhysRegId *',
> which requires 8 byte alignment
> 0x1c1ed9ac: note: pointer points here
>   00 00 00 00 00 00 00 00  50 d9 1e 1c 00 00 00 00  70 8d 20 1c 00 00
> 00 00  40 58 1e 1c 00 00 00 00
>   ^
> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
> build/ARM_clang/cpu/o3/dyn_inst.hh:252:29 in
> build/ARM_clang/cpu/o3/dyn_inst.hh:335:13: runtime error: store to
> misaligned address 0x1c1ed9bc for type 'gem5::PhysRegIdPtr' (aka
> 'gem5::PhysRegId *'), which requires 8 byte alignment
> 0x1c1ed9bc: note: pointer points here
>   70 8d 20 1c 00 00 00 00  40 58 1e 1c 00 00 00 00  1a 00 00 00 00 00
> 00 00  1a 00 00 00 00 00 00 00
>   ^
> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
> build/ARM_clang/cpu/o3/dyn_inst.hh:335:13 in
> build/ARM_clang/cpu/o3/dyn_inst.hh:307:13: runtime error: store to
> misaligned address 0x1c1ed9ac for type 'gem5::PhysRegIdPtr' (aka
> 'gem5::PhysRegId *'), which requires 8 byte alignment

[gem5-dev] Re: Build failed in Jenkins: nightly #27

2021-11-05 Thread Gabe Black via gem5-dev 
On Fri, Nov 5, 2021 at 11:18 AM Jason Lowe-Power 
wrote:

> Here's what the undefined behavior sanitizer says with these patches
> applied. Also, the backtrace from the core dump is shown.
>
>
> build/ARM_clang/base/stats/text.cc:234:13: runtime error: load of value
> 32, which is not a valid value for type 'bool'
> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
> build/ARM_clang/base/stats/text.cc:234:13 in
> gem5 has encountered a segmentation fault!
>

I think this will fix the undefined behavior at least:

https://gem5-review.googlesource.com/c/public/gem5/+/52483

The fact that the segfault happens after this point says even more that
this is some sort of cleanup thing, since the undefined behavior is from
when it's printing stats to a text file.


>
> --- BEGIN LIBC BACKTRACE ---
> build/ARM_clang/gem5.opt[0x1c7684a]
> build/ARM_clang/gem5.opt[0x1cc6255]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x153c0)[0x7feaafd103c0]
>
> /lib/x86_64-linux-gnu/libtcmalloc.so.4(_ZN8tcmalloc11ThreadCache21ReleaseToCentralCacheEPNS0_8FreeListEji+0x93)[0x7feaaf9b9f83]
>
> /lib/x86_64-linux-gnu/libtcmalloc.so.4(_ZN8tcmalloc11ThreadCache8ScavengeEv+0x4e)[0x7feaaf9ba2de]
> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0x2707e8)[0x7feaaff8e7e8]
>
> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyState_ClearModules+0xb5)[0x7feaafead745]
>
> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(PyImport_Cleanup+0x4f7)[0x7feaafec61c7]
>
> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(Py_FinalizeEx+0x90)[0x7feaafeb1690]
> build/ARM_clang/gem5.opt[0x1cc8a07]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x7feaaf28e0b3]
> build/ARM_clang/gem5.opt[0x5e078e]
> --- END LIBC BACKTRACE ---
>

Is there some sort of bookkeeping bug in the stats interaction between c++
and python? This is a crash in the heap manager triggered by the python
interpreter doing some sort of cleanup. I can imagine this being a latent
bug where something was corrupted earlier and it's just falling over now,
but this makes sense for three reasons. First, python stats related
problems would likely show up at the end when the stats are printed out
which is done partially through python. Second, python's reference counting
stuff would be easy to make a mistake with since it's complicated and
sometimes has to be handled manually. Third, when running valgrind, I
suppressed errors in the python library which would hide any bad behavior
right before the segfault.



>
> Cheers,
> Jason
>
> On Fri, Nov 5, 2021 at 7:28 AM Gabe Black  wrote:
>
>> Can you try this pair of changes?
>>
>> https://gem5-review.googlesource.com/c/public/gem5/+/52485/1
>>
>> I think this should at least fix the undefined behavior, but when I tried
>> to test it it took an hour and a half to unsuccessfully compile with the
>> sanitizers for build/ARM so I gave up.
>>
>> I'm hopeful this could also fix the segfault?
>>
>> Gabe
>>
>> On Thu, Nov 4, 2021 at 4:18 PM Gabe Black  wrote:
>>
>>> Oh, yes, that does look very suspicious. I'll have to take a closer look
>>> at that!
>>>
>>> Gabe
>>>
>>> On Thu, Nov 4, 2021 at 3:02 PM Jason Lowe-Power 
>>> wrote:
>>>
 Glad you asked! I didn't look closely enough at the output.

 Here's an error that looks suspicious (The whole file is attached.)

 build/ARM_clang/cpu/o3/dyn_inst.hh:252:29: runtime error: constructor
 call on misaligned address 0x1c1ed9ac for type 'gem5::PhysRegId *',
 which requires 8 byte alignment
 0x1c1ed9ac: note: pointer points here
   00 00 00 00 00 00 00 00  50 d9 1e 1c 00 00 00 00  70 8d 20 1c 00 00
 00 00  40 58 1e 1c 00 00 00 00
   ^
 SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
 build/ARM_clang/cpu/o3/dyn_inst.hh:252:29 in
 build/ARM_clang/cpu/o3/dyn_inst.hh:335:13: runtime error: store to
 misaligned address 0x1c1ed9bc for type 'gem5::PhysRegIdPtr' (aka
 'gem5::PhysRegId *'), which requires 8 byte alignment
 0x1c1ed9bc: note: pointer points here
   70 8d 20 1c 00 00 00 00  40 58 1e 1c 00 00 00 00  1a 00 00 00 00 00
 00 00  1a 00 00 00 00 00 00 00
   ^
 SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
 build/ARM_clang/cpu/o3/dyn_inst.hh:335:13 in
 build/ARM_clang/cpu/o3/dyn_inst.hh:307:13: runtime error: store to
 misaligned address 0x1c1ed9ac for type 'gem5::PhysRegIdPtr' (aka
 'gem5::PhysRegId *'), which requires 8 byte alignment
 0x1c1ed9ac: note: pointer points here
   00 00 00 00 00 00 00 00  50 d9 1e 1c 00 00 00 00  70 8d 20 1c 00 00
 fb 1c  00 00 00 00 80 10 fb 1c
   ^
 SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
 build/ARM_clang/cpu/o3/dyn_inst.hh:307:13 in
 build/ARM_clang/cpu/o3/dyn_inst.hh:322:13: runtime error: store to
 misaligned address 0x1c1ed9b4 for type 'gem5::PhysRegIdPtr' (aka
 'gem5::PhysRegId *'), which requires 8 byte alignment
 0x1c1ed9b4: note: pointer points here

[gem5-dev] Re: Build failed in Jenkins: nightly #27

2021-11-05 Thread Jason Lowe-Power via gem5-dev 
Here's what the undefined behavior sanitizer says with these patches
applied. Also, the backtrace from the core dump is shown.


build/ARM_clang/base/stats/text.cc:234:13: runtime error: load of value 32,
which is not a valid value for type 'bool'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
build/ARM_clang/base/stats/text.cc:234:13 in
gem5 has encountered a segmentation fault!

--- BEGIN LIBC BACKTRACE ---
build/ARM_clang/gem5.opt[0x1c7684a]
build/ARM_clang/gem5.opt[0x1cc6255]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x153c0)[0x7feaafd103c0]
/lib/x86_64-linux-gnu/libtcmalloc.so.4(_ZN8tcmalloc11ThreadCache21ReleaseToCentralCacheEPNS0_8FreeListEji+0x93)[0x7feaaf9b9f83]
/lib/x86_64-linux-gnu/libtcmalloc.so.4(_ZN8tcmalloc11ThreadCache8ScavengeEv+0x4e)[0x7feaaf9ba2de]
/lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0x2707e8)[0x7feaaff8e7e8]
/lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyState_ClearModules+0xb5)[0x7feaafead745]
/lib/x86_64-linux-gnu/libpython3.8.so.1.0(PyImport_Cleanup+0x4f7)[0x7feaafec61c7]
/lib/x86_64-linux-gnu/libpython3.8.so.1.0(Py_FinalizeEx+0x90)[0x7feaafeb1690]
build/ARM_clang/gem5.opt[0x1cc8a07]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x7feaaf28e0b3]
build/ARM_clang/gem5.opt[0x5e078e]
--- END LIBC BACKTRACE ---

Cheers,
Jason

On Fri, Nov 5, 2021 at 7:28 AM Gabe Black  wrote:

> Can you try this pair of changes?
>
> https://gem5-review.googlesource.com/c/public/gem5/+/52485/1
>
> I think this should at least fix the undefined behavior, but when I tried
> to test it it took an hour and a half to unsuccessfully compile with the
> sanitizers for build/ARM so I gave up.
>
> I'm hopeful this could also fix the segfault?
>
> Gabe
>
> On Thu, Nov 4, 2021 at 4:18 PM Gabe Black  wrote:
>
>> Oh, yes, that does look very suspicious. I'll have to take a closer look
>> at that!
>>
>> Gabe
>>
>> On Thu, Nov 4, 2021 at 3:02 PM Jason Lowe-Power 
>> wrote:
>>
>>> Glad you asked! I didn't look closely enough at the output.
>>>
>>> Here's an error that looks suspicious (The whole file is attached.)
>>>
>>> build/ARM_clang/cpu/o3/dyn_inst.hh:252:29: runtime error: constructor
>>> call on misaligned address 0x1c1ed9ac for type 'gem5::PhysRegId *',
>>> which requires 8 byte alignment
>>> 0x1c1ed9ac: note: pointer points here
>>>   00 00 00 00 00 00 00 00  50 d9 1e 1c 00 00 00 00  70 8d 20 1c 00 00 00
>>> 00  40 58 1e 1c 00 00 00 00
>>>   ^
>>> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
>>> build/ARM_clang/cpu/o3/dyn_inst.hh:252:29 in
>>> build/ARM_clang/cpu/o3/dyn_inst.hh:335:13: runtime error: store to
>>> misaligned address 0x1c1ed9bc for type 'gem5::PhysRegIdPtr' (aka
>>> 'gem5::PhysRegId *'), which requires 8 byte alignment
>>> 0x1c1ed9bc: note: pointer points here
>>>   70 8d 20 1c 00 00 00 00  40 58 1e 1c 00 00 00 00  1a 00 00 00 00 00 00
>>> 00  1a 00 00 00 00 00 00 00
>>>   ^
>>> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
>>> build/ARM_clang/cpu/o3/dyn_inst.hh:335:13 in
>>> build/ARM_clang/cpu/o3/dyn_inst.hh:307:13: runtime error: store to
>>> misaligned address 0x1c1ed9ac for type 'gem5::PhysRegIdPtr' (aka
>>> 'gem5::PhysRegId *'), which requires 8 byte alignment
>>> 0x1c1ed9ac: note: pointer points here
>>>   00 00 00 00 00 00 00 00  50 d9 1e 1c 00 00 00 00  70 8d 20 1c 00 00 fb
>>> 1c  00 00 00 00 80 10 fb 1c
>>>   ^
>>> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
>>> build/ARM_clang/cpu/o3/dyn_inst.hh:307:13 in
>>> build/ARM_clang/cpu/o3/dyn_inst.hh:322:13: runtime error: store to
>>> misaligned address 0x1c1ed9b4 for type 'gem5::PhysRegIdPtr' (aka
>>> 'gem5::PhysRegId *'), which requires 8 byte alignment
>>> 0x1c1ed9b4: note: pointer points here
>>>   00 00 00 00 00 00 00 00  70 8d 20 1c 00 00 fb 1c  00 00 00 00 80 10 fb
>>> 1c  00 00 00 00 50 0d fb 1c
>>>   ^
>>> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
>>> build/ARM_clang/cpu/o3/dyn_inst.hh:322:13 in
>>> build/ARM_clang/cpu/o3/dyn_inst.hh:300:20: runtime error: load of
>>> misaligned address 0x1c1ed9ac for type 'gem5::PhysRegIdPtr' (aka
>>> 'gem5::PhysRegId *'), which requires 8 byte alignment
>>> 0x1c1ed9ac: note: pointer points here
>>>   00 00 00 00 f0 8f 01 18  00 00 00 00 c0 8c 01 18  00 00 00 00 00 00 fb
>>> 1c  00 00 00 00 80 10 fb 1c
>>>   ^
>>> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
>>> build/ARM_clang/cpu/o3/dyn_inst.hh:300:20 in
>>> build/ARM_clang/cpu/o3/dyn_inst.hh:329:20: runtime error: load of
>>> misaligned address 0x1d223754 for type 'gem5::PhysRegIdPtr' (aka
>>> 'gem5::PhysRegId *'), which requires 8 byte alignment
>>> 0x1d223754: note: pointer points here
>>>   00 00 00 00 f0 8f 01 18  00 00 00 00 18 60 01 1d  00 00 00 00 78 60 01
>>> 1d  00 00 00 00 78 60 01 1d
>>>   ^
>>> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
>>> build/ARM_clang/cpu/o3/dyn_inst.hh:329:20 in
>>>

[gem5-dev] Re: Build failed in Jenkins: nightly #27

2021-11-05 Thread Gabe Black via gem5-dev 
Can you try this pair of changes?

https://gem5-review.googlesource.com/c/public/gem5/+/52485/1

I think this should at least fix the undefined behavior, but when I tried
to test it it took an hour and a half to unsuccessfully compile with the
sanitizers for build/ARM so I gave up.

I'm hopeful this could also fix the segfault?

Gabe

On Thu, Nov 4, 2021 at 4:18 PM Gabe Black  wrote:

> Oh, yes, that does look very suspicious. I'll have to take a closer look
> at that!
>
> Gabe
>
> On Thu, Nov 4, 2021 at 3:02 PM Jason Lowe-Power 
> wrote:
>
>> Glad you asked! I didn't look closely enough at the output.
>>
>> Here's an error that looks suspicious (The whole file is attached.)
>>
>> build/ARM_clang/cpu/o3/dyn_inst.hh:252:29: runtime error: constructor
>> call on misaligned address 0x1c1ed9ac for type 'gem5::PhysRegId *',
>> which requires 8 byte alignment
>> 0x1c1ed9ac: note: pointer points here
>>   00 00 00 00 00 00 00 00  50 d9 1e 1c 00 00 00 00  70 8d 20 1c 00 00 00
>> 00  40 58 1e 1c 00 00 00 00
>>   ^
>> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
>> build/ARM_clang/cpu/o3/dyn_inst.hh:252:29 in
>> build/ARM_clang/cpu/o3/dyn_inst.hh:335:13: runtime error: store to
>> misaligned address 0x1c1ed9bc for type 'gem5::PhysRegIdPtr' (aka
>> 'gem5::PhysRegId *'), which requires 8 byte alignment
>> 0x1c1ed9bc: note: pointer points here
>>   70 8d 20 1c 00 00 00 00  40 58 1e 1c 00 00 00 00  1a 00 00 00 00 00 00
>> 00  1a 00 00 00 00 00 00 00
>>   ^
>> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
>> build/ARM_clang/cpu/o3/dyn_inst.hh:335:13 in
>> build/ARM_clang/cpu/o3/dyn_inst.hh:307:13: runtime error: store to
>> misaligned address 0x1c1ed9ac for type 'gem5::PhysRegIdPtr' (aka
>> 'gem5::PhysRegId *'), which requires 8 byte alignment
>> 0x1c1ed9ac: note: pointer points here
>>   00 00 00 00 00 00 00 00  50 d9 1e 1c 00 00 00 00  70 8d 20 1c 00 00 fb
>> 1c  00 00 00 00 80 10 fb 1c
>>   ^
>> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
>> build/ARM_clang/cpu/o3/dyn_inst.hh:307:13 in
>> build/ARM_clang/cpu/o3/dyn_inst.hh:322:13: runtime error: store to
>> misaligned address 0x1c1ed9b4 for type 'gem5::PhysRegIdPtr' (aka
>> 'gem5::PhysRegId *'), which requires 8 byte alignment
>> 0x1c1ed9b4: note: pointer points here
>>   00 00 00 00 00 00 00 00  70 8d 20 1c 00 00 fb 1c  00 00 00 00 80 10 fb
>> 1c  00 00 00 00 50 0d fb 1c
>>   ^
>> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
>> build/ARM_clang/cpu/o3/dyn_inst.hh:322:13 in
>> build/ARM_clang/cpu/o3/dyn_inst.hh:300:20: runtime error: load of
>> misaligned address 0x1c1ed9ac for type 'gem5::PhysRegIdPtr' (aka
>> 'gem5::PhysRegId *'), which requires 8 byte alignment
>> 0x1c1ed9ac: note: pointer points here
>>   00 00 00 00 f0 8f 01 18  00 00 00 00 c0 8c 01 18  00 00 00 00 00 00 fb
>> 1c  00 00 00 00 80 10 fb 1c
>>   ^
>> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
>> build/ARM_clang/cpu/o3/dyn_inst.hh:300:20 in
>> build/ARM_clang/cpu/o3/dyn_inst.hh:329:20: runtime error: load of
>> misaligned address 0x1d223754 for type 'gem5::PhysRegIdPtr' (aka
>> 'gem5::PhysRegId *'), which requires 8 byte alignment
>> 0x1d223754: note: pointer points here
>>   00 00 00 00 f0 8f 01 18  00 00 00 00 18 60 01 1d  00 00 00 00 78 60 01
>> 1d  00 00 00 00 78 60 01 1d
>>   ^
>> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
>> build/ARM_clang/cpu/o3/dyn_inst.hh:329:20 in
>> build/ARM_clang/cpu/o3/dyn_inst.hh:315:20: runtime error: load of
>> misaligned address 0x1c1ecba4 for type 'gem5::PhysRegIdPtr' (aka
>> 'gem5::PhysRegId *'), which requires 8 byte alignment
>> 0x1c1ecba4: note: pointer points here
>>   00 00 00 00 f8 90 01 18  00 00 00 00 f8 90 01 18  00 00 00 00 c0 60 01
>> 1d  00 00 00 00 78 60 01 1d
>>   ^
>> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
>> build/ARM_clang/cpu/o3/dyn_inst.hh:315:20 in
>>
>>
>> Cheers,
>> Jason
>>
>> On Thu, Nov 4, 2021 at 2:51 PM Gabe Black  wrote:
>>
>>> Did you find anything with ASAN?
>>>
>>> Gabe
>>>
>>> On Thu, Nov 4, 2021, 12:59 PM Gabe Black  wrote:
>>>
 I don't know if they do, and frankly even the unique_ptr change could
 since that could fix heap corruption, even though it's unlikely since I
 don't think this regression uses any of that code (except maybe VIO). We
 don't actually *know* that that change is at fault, even though I agree
 that it seems like a reasonable guess. This could be one of those bugs
 where something totally unrelated is wrong, and another change just shifts
 things around until some address lines up with something bad.

 As valgrind grinds on, I think there's a good chance of identifying
 exactly what the problem is. I think that should happen in the next day or
 two, hopefully.

 Gabe

 On Thu, Nov 4, 2021 at 9:55 AM Jason Lowe-Power 
 wrote:

[gem5-dev] Re: Build failed in Jenkins: nightly #27

2021-11-04 Thread Gabe Black via gem5-dev 
Oh, yes, that does look very suspicious. I'll have to take a closer look at
that!

Gabe

On Thu, Nov 4, 2021 at 3:02 PM Jason Lowe-Power  wrote:

> Glad you asked! I didn't look closely enough at the output.
>
> Here's an error that looks suspicious (The whole file is attached.)
>
> build/ARM_clang/cpu/o3/dyn_inst.hh:252:29: runtime error: constructor call
> on misaligned address 0x1c1ed9ac for type 'gem5::PhysRegId *', which
> requires 8 byte alignment
> 0x1c1ed9ac: note: pointer points here
>   00 00 00 00 00 00 00 00  50 d9 1e 1c 00 00 00 00  70 8d 20 1c 00 00 00
> 00  40 58 1e 1c 00 00 00 00
>   ^
> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
> build/ARM_clang/cpu/o3/dyn_inst.hh:252:29 in
> build/ARM_clang/cpu/o3/dyn_inst.hh:335:13: runtime error: store to
> misaligned address 0x1c1ed9bc for type 'gem5::PhysRegIdPtr' (aka
> 'gem5::PhysRegId *'), which requires 8 byte alignment
> 0x1c1ed9bc: note: pointer points here
>   70 8d 20 1c 00 00 00 00  40 58 1e 1c 00 00 00 00  1a 00 00 00 00 00 00
> 00  1a 00 00 00 00 00 00 00
>   ^
> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
> build/ARM_clang/cpu/o3/dyn_inst.hh:335:13 in
> build/ARM_clang/cpu/o3/dyn_inst.hh:307:13: runtime error: store to
> misaligned address 0x1c1ed9ac for type 'gem5::PhysRegIdPtr' (aka
> 'gem5::PhysRegId *'), which requires 8 byte alignment
> 0x1c1ed9ac: note: pointer points here
>   00 00 00 00 00 00 00 00  50 d9 1e 1c 00 00 00 00  70 8d 20 1c 00 00 fb
> 1c  00 00 00 00 80 10 fb 1c
>   ^
> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
> build/ARM_clang/cpu/o3/dyn_inst.hh:307:13 in
> build/ARM_clang/cpu/o3/dyn_inst.hh:322:13: runtime error: store to
> misaligned address 0x1c1ed9b4 for type 'gem5::PhysRegIdPtr' (aka
> 'gem5::PhysRegId *'), which requires 8 byte alignment
> 0x1c1ed9b4: note: pointer points here
>   00 00 00 00 00 00 00 00  70 8d 20 1c 00 00 fb 1c  00 00 00 00 80 10 fb
> 1c  00 00 00 00 50 0d fb 1c
>   ^
> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
> build/ARM_clang/cpu/o3/dyn_inst.hh:322:13 in
> build/ARM_clang/cpu/o3/dyn_inst.hh:300:20: runtime error: load of
> misaligned address 0x1c1ed9ac for type 'gem5::PhysRegIdPtr' (aka
> 'gem5::PhysRegId *'), which requires 8 byte alignment
> 0x1c1ed9ac: note: pointer points here
>   00 00 00 00 f0 8f 01 18  00 00 00 00 c0 8c 01 18  00 00 00 00 00 00 fb
> 1c  00 00 00 00 80 10 fb 1c
>   ^
> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
> build/ARM_clang/cpu/o3/dyn_inst.hh:300:20 in
> build/ARM_clang/cpu/o3/dyn_inst.hh:329:20: runtime error: load of
> misaligned address 0x1d223754 for type 'gem5::PhysRegIdPtr' (aka
> 'gem5::PhysRegId *'), which requires 8 byte alignment
> 0x1d223754: note: pointer points here
>   00 00 00 00 f0 8f 01 18  00 00 00 00 18 60 01 1d  00 00 00 00 78 60 01
> 1d  00 00 00 00 78 60 01 1d
>   ^
> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
> build/ARM_clang/cpu/o3/dyn_inst.hh:329:20 in
> build/ARM_clang/cpu/o3/dyn_inst.hh:315:20: runtime error: load of
> misaligned address 0x1c1ecba4 for type 'gem5::PhysRegIdPtr' (aka
> 'gem5::PhysRegId *'), which requires 8 byte alignment
> 0x1c1ecba4: note: pointer points here
>   00 00 00 00 f8 90 01 18  00 00 00 00 f8 90 01 18  00 00 00 00 c0 60 01
> 1d  00 00 00 00 78 60 01 1d
>   ^
> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
> build/ARM_clang/cpu/o3/dyn_inst.hh:315:20 in
>
>
> Cheers,
> Jason
>
> On Thu, Nov 4, 2021 at 2:51 PM Gabe Black  wrote:
>
>> Did you find anything with ASAN?
>>
>> Gabe
>>
>> On Thu, Nov 4, 2021, 12:59 PM Gabe Black  wrote:
>>
>>> I don't know if they do, and frankly even the unique_ptr change could
>>> since that could fix heap corruption, even though it's unlikely since I
>>> don't think this regression uses any of that code (except maybe VIO). We
>>> don't actually *know* that that change is at fault, even though I agree
>>> that it seems like a reasonable guess. This could be one of those bugs
>>> where something totally unrelated is wrong, and another change just shifts
>>> things around until some address lines up with something bad.
>>>
>>> As valgrind grinds on, I think there's a good chance of identifying
>>> exactly what the problem is. I think that should happen in the next day or
>>> two, hopefully.
>>>
>>> Gabe
>>>
>>> On Thu, Nov 4, 2021 at 9:55 AM Jason Lowe-Power 
>>> wrote:
>>>
 Hey Gabe,

 Do these fix the nightly regression? If not, we may need to back out
 "4fe56ff72 - (3 months ago) arch-arm,cpu: Replace rename modes with split
 reg/elem register files." until we have a fix.

 Cheers,
 Jason

 On Thu, Nov 4, 2021 at 12:13 AM Gabe Black 
 wrote:

> Valgrind hasn't finished, but what it found so far is attached. I went
> through it and have the following changes which should address these
>

[gem5-dev] Re: Build failed in Jenkins: nightly #27

2021-11-04 Thread Jason Lowe-Power via gem5-dev 
Glad you asked! I didn't look closely enough at the output.

Here's an error that looks suspicious (The whole file is attached.)

build/ARM_clang/cpu/o3/dyn_inst.hh:252:29: runtime error: constructor call
on misaligned address 0x1c1ed9ac for type 'gem5::PhysRegId *', which
requires 8 byte alignment
0x1c1ed9ac: note: pointer points here
  00 00 00 00 00 00 00 00  50 d9 1e 1c 00 00 00 00  70 8d 20 1c 00 00 00 00
 40 58 1e 1c 00 00 00 00
  ^
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
build/ARM_clang/cpu/o3/dyn_inst.hh:252:29 in
build/ARM_clang/cpu/o3/dyn_inst.hh:335:13: runtime error: store to
misaligned address 0x1c1ed9bc for type 'gem5::PhysRegIdPtr' (aka
'gem5::PhysRegId *'), which requires 8 byte alignment
0x1c1ed9bc: note: pointer points here
  70 8d 20 1c 00 00 00 00  40 58 1e 1c 00 00 00 00  1a 00 00 00 00 00 00 00
 1a 00 00 00 00 00 00 00
  ^
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
build/ARM_clang/cpu/o3/dyn_inst.hh:335:13 in
build/ARM_clang/cpu/o3/dyn_inst.hh:307:13: runtime error: store to
misaligned address 0x1c1ed9ac for type 'gem5::PhysRegIdPtr' (aka
'gem5::PhysRegId *'), which requires 8 byte alignment
0x1c1ed9ac: note: pointer points here
  00 00 00 00 00 00 00 00  50 d9 1e 1c 00 00 00 00  70 8d 20 1c 00 00 fb 1c
 00 00 00 00 80 10 fb 1c
  ^
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
build/ARM_clang/cpu/o3/dyn_inst.hh:307:13 in
build/ARM_clang/cpu/o3/dyn_inst.hh:322:13: runtime error: store to
misaligned address 0x1c1ed9b4 for type 'gem5::PhysRegIdPtr' (aka
'gem5::PhysRegId *'), which requires 8 byte alignment
0x1c1ed9b4: note: pointer points here
  00 00 00 00 00 00 00 00  70 8d 20 1c 00 00 fb 1c  00 00 00 00 80 10 fb 1c
 00 00 00 00 50 0d fb 1c
  ^
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
build/ARM_clang/cpu/o3/dyn_inst.hh:322:13 in
build/ARM_clang/cpu/o3/dyn_inst.hh:300:20: runtime error: load of
misaligned address 0x1c1ed9ac for type 'gem5::PhysRegIdPtr' (aka
'gem5::PhysRegId *'), which requires 8 byte alignment
0x1c1ed9ac: note: pointer points here
  00 00 00 00 f0 8f 01 18  00 00 00 00 c0 8c 01 18  00 00 00 00 00 00 fb 1c
 00 00 00 00 80 10 fb 1c
  ^
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
build/ARM_clang/cpu/o3/dyn_inst.hh:300:20 in
build/ARM_clang/cpu/o3/dyn_inst.hh:329:20: runtime error: load of
misaligned address 0x1d223754 for type 'gem5::PhysRegIdPtr' (aka
'gem5::PhysRegId *'), which requires 8 byte alignment
0x1d223754: note: pointer points here
  00 00 00 00 f0 8f 01 18  00 00 00 00 18 60 01 1d  00 00 00 00 78 60 01 1d
 00 00 00 00 78 60 01 1d
  ^
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
build/ARM_clang/cpu/o3/dyn_inst.hh:329:20 in
build/ARM_clang/cpu/o3/dyn_inst.hh:315:20: runtime error: load of
misaligned address 0x1c1ecba4 for type 'gem5::PhysRegIdPtr' (aka
'gem5::PhysRegId *'), which requires 8 byte alignment
0x1c1ecba4: note: pointer points here
  00 00 00 00 f8 90 01 18  00 00 00 00 f8 90 01 18  00 00 00 00 c0 60 01 1d
 00 00 00 00 78 60 01 1d
  ^
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
build/ARM_clang/cpu/o3/dyn_inst.hh:315:20 in


Cheers,
Jason

On Thu, Nov 4, 2021 at 2:51 PM Gabe Black  wrote:

> Did you find anything with ASAN?
>
> Gabe
>
> On Thu, Nov 4, 2021, 12:59 PM Gabe Black  wrote:
>
>> I don't know if they do, and frankly even the unique_ptr change could
>> since that could fix heap corruption, even though it's unlikely since I
>> don't think this regression uses any of that code (except maybe VIO). We
>> don't actually *know* that that change is at fault, even though I agree
>> that it seems like a reasonable guess. This could be one of those bugs
>> where something totally unrelated is wrong, and another change just shifts
>> things around until some address lines up with something bad.
>>
>> As valgrind grinds on, I think there's a good chance of identifying
>> exactly what the problem is. I think that should happen in the next day or
>> two, hopefully.
>>
>> Gabe
>>
>> On Thu, Nov 4, 2021 at 9:55 AM Jason Lowe-Power 
>> wrote:
>>
>>> Hey Gabe,
>>>
>>> Do these fix the nightly regression? If not, we may need to back out
>>> "4fe56ff72 - (3 months ago) arch-arm,cpu: Replace rename modes with split
>>> reg/elem register files." until we have a fix.
>>>
>>> Cheers,
>>> Jason
>>>
>>> On Thu, Nov 4, 2021 at 12:13 AM Gabe Black  wrote:
>>>
 Valgrind hasn't finished, but what it found so far is attached. I went
 through it and have the following changes which should address these
 uninitialized accesses, and an inefficiency in the cache it found by
 accident.

 https://gem5-review.googlesource.com/c/public/gem5/+/52403
 https://gem5-review.googlesource.com/c/public/gem5/+/52404
 https://gem5-review.googlesource.com/c/public/gem5/+/52405

[gem5-dev] Re: Build failed in Jenkins: nightly #27

2021-11-04 Thread Gabe Black via gem5-dev 
Did you find anything with ASAN?

Gabe

On Thu, Nov 4, 2021, 12:59 PM Gabe Black  wrote:

> I don't know if they do, and frankly even the unique_ptr change could
> since that could fix heap corruption, even though it's unlikely since I
> don't think this regression uses any of that code (except maybe VIO). We
> don't actually *know* that that change is at fault, even though I agree
> that it seems like a reasonable guess. This could be one of those bugs
> where something totally unrelated is wrong, and another change just shifts
> things around until some address lines up with something bad.
>
> As valgrind grinds on, I think there's a good chance of identifying
> exactly what the problem is. I think that should happen in the next day or
> two, hopefully.
>
> Gabe
>
> On Thu, Nov 4, 2021 at 9:55 AM Jason Lowe-Power 
> wrote:
>
>> Hey Gabe,
>>
>> Do these fix the nightly regression? If not, we may need to back out
>> "4fe56ff72 - (3 months ago) arch-arm,cpu: Replace rename modes with split
>> reg/elem register files." until we have a fix.
>>
>> Cheers,
>> Jason
>>
>> On Thu, Nov 4, 2021 at 12:13 AM Gabe Black  wrote:
>>
>>> Valgrind hasn't finished, but what it found so far is attached. I went
>>> through it and have the following changes which should address these
>>> uninitialized accesses, and an inefficiency in the cache it found by
>>> accident.
>>>
>>> https://gem5-review.googlesource.com/c/public/gem5/+/52403
>>> https://gem5-review.googlesource.com/c/public/gem5/+/52404
>>> https://gem5-review.googlesource.com/c/public/gem5/+/52405
>>> https://gem5-review.googlesource.com/c/public/gem5/+/52406
>>>
>>> Gabe
>>>
>>> On Wed, Nov 3, 2021 at 12:45 PM Jason Lowe-Power 
>>> wrote:
>>>
 Here's my data:

 BAD * 4fe56ff72 - (3 months ago) arch-arm,cpu: Replace rename modes
 with split reg/elem register files. - Gabe Black
 GOOD * 25138cbb7 - (4 weeks ago) arch: Simplify and tidy up PCState
 classes. - Gabe Black
 * 930986332 - (7 days ago) mem: Fix whitespace in
 mem/ruby/system/Sequencer.py. - Gabe Black
 GOOD * 69e6ea485 - (3 months ago) arch-arm: Add walkBits method to
 PageTableOps - Giacomo Travaglini
 * 1268c6ec3 - (2 weeks ago) arch-arm: Expose LookupLevel enum to the
 python world - Giacomo Travaglini

 I've tested this a number of times and tested commits before and after
 these commits. I have increasing confidence (though no certainty) that
 4fe56ff72 is the culprit.

 I'm running a UBSAN now to see if that will help at all.

 Cheers,
 Jason

 On Tue, Nov 2, 2021 at 5:28 PM Gabe Black  wrote:

> I'm going to kill it now, and restart it with --track-origins=yes and
> in a separate tree so I can keep working on other things while it runs.
>
> Gabe
>
> On Tue, Nov 2, 2021 at 5:11 PM Gabe Black 
> wrote:
>
>> It's still running, but here's what it's found so far.
>>
>> Gabe
>>
>> On Tue, Nov 2, 2021 at 7:48 AM Jason Lowe-Power 
>> wrote:
>>
>>> Thanks! I tried a bisect but, tbh, it wasn't helpful since the error
>>> doesn't seem to be deterministic.
>>>
>>> As more evidence that it's a memory issue, the backtrace that I saw
>>> with GDB was something a bit different.
>>>
>>> Cheers,
>>> Jason
>>>
>>> On Tue, Nov 2, 2021 at 5:07 AM Gabe Black 
>>> wrote:
>>>
 I'm running it under valgrind to see if that tells me anything,
 which is going to take a while. I'll let you know if/when it finishes.

 Gabe

 On Tue, Nov 2, 2021 at 4:36 AM Gabe Black 
 wrote:

> Attached is a log of a failing run, and backtrace of the segfault.
>
> Gabe
>
> On Tue, Nov 2, 2021 at 4:17 AM Gabe Black 
> wrote:
>
>> Ok, I reproduced the segfault once, but then running again in gdb
>> it exited normally. I'm pretty confident it's something to do with 
>> things
>> getting cleaned up and/or destructed at the end of the simulation, 
>> but
>> until I catch something in the act of exploding I won't be able to 
>> nail
>> down specifically what's doing it.
>>
>> Gabe
>>
>> On Tue, Nov 2, 2021 at 3:46 AM Gabe Black 
>> wrote:
>>
>>> A clean build seems to have fixed the IdeDisk problem.
>>>
>>> On Tue, Nov 2, 2021 at 3:35 AM Gabe Black 
>>> wrote:
>>>
 Can you get a backtrace from it? Or run it in valgrind? I'm
 trying to use the command line you provided locally, but it's 
 complaining
 about not being able to find IdeDisk which is very strange... I 
 don't think
 I have an account on the machine where this ran, but ideally I'll 
 be able
 to reproduce it locally where it

[gem5-dev] Re: Build failed in Jenkins: nightly #27

2021-11-04 Thread Gabe Black via gem5-dev 
I don't know if they do, and frankly even the unique_ptr change could since
that could fix heap corruption, even though it's unlikely since I don't
think this regression uses any of that code (except maybe VIO). We don't
actually *know* that that change is at fault, even though I agree that it
seems like a reasonable guess. This could be one of those bugs where
something totally unrelated is wrong, and another change just shifts things
around until some address lines up with something bad.

As valgrind grinds on, I think there's a good chance of identifying exactly
what the problem is. I think that should happen in the next day or two,
hopefully.

Gabe

On Thu, Nov 4, 2021 at 9:55 AM Jason Lowe-Power  wrote:

> Hey Gabe,
>
> Do these fix the nightly regression? If not, we may need to back out
> "4fe56ff72 - (3 months ago) arch-arm,cpu: Replace rename modes with split
> reg/elem register files." until we have a fix.
>
> Cheers,
> Jason
>
> On Thu, Nov 4, 2021 at 12:13 AM Gabe Black  wrote:
>
>> Valgrind hasn't finished, but what it found so far is attached. I went
>> through it and have the following changes which should address these
>> uninitialized accesses, and an inefficiency in the cache it found by
>> accident.
>>
>> https://gem5-review.googlesource.com/c/public/gem5/+/52403
>> https://gem5-review.googlesource.com/c/public/gem5/+/52404
>> https://gem5-review.googlesource.com/c/public/gem5/+/52405
>> https://gem5-review.googlesource.com/c/public/gem5/+/52406
>>
>> Gabe
>>
>> On Wed, Nov 3, 2021 at 12:45 PM Jason Lowe-Power 
>> wrote:
>>
>>> Here's my data:
>>>
>>> BAD * 4fe56ff72 - (3 months ago) arch-arm,cpu: Replace rename modes with
>>> split reg/elem register files. - Gabe Black
>>> GOOD * 25138cbb7 - (4 weeks ago) arch: Simplify and tidy up PCState
>>> classes. - Gabe Black
>>> * 930986332 - (7 days ago) mem: Fix whitespace in
>>> mem/ruby/system/Sequencer.py. - Gabe Black
>>> GOOD * 69e6ea485 - (3 months ago) arch-arm: Add walkBits method to
>>> PageTableOps - Giacomo Travaglini
>>> * 1268c6ec3 - (2 weeks ago) arch-arm: Expose LookupLevel enum to the
>>> python world - Giacomo Travaglini
>>>
>>> I've tested this a number of times and tested commits before and after
>>> these commits. I have increasing confidence (though no certainty) that
>>> 4fe56ff72 is the culprit.
>>>
>>> I'm running a UBSAN now to see if that will help at all.
>>>
>>> Cheers,
>>> Jason
>>>
>>> On Tue, Nov 2, 2021 at 5:28 PM Gabe Black  wrote:
>>>
 I'm going to kill it now, and restart it with --track-origins=yes and
 in a separate tree so I can keep working on other things while it runs.

 Gabe

 On Tue, Nov 2, 2021 at 5:11 PM Gabe Black  wrote:

> It's still running, but here's what it's found so far.
>
> Gabe
>
> On Tue, Nov 2, 2021 at 7:48 AM Jason Lowe-Power 
> wrote:
>
>> Thanks! I tried a bisect but, tbh, it wasn't helpful since the error
>> doesn't seem to be deterministic.
>>
>> As more evidence that it's a memory issue, the backtrace that I saw
>> with GDB was something a bit different.
>>
>> Cheers,
>> Jason
>>
>> On Tue, Nov 2, 2021 at 5:07 AM Gabe Black 
>> wrote:
>>
>>> I'm running it under valgrind to see if that tells me anything,
>>> which is going to take a while. I'll let you know if/when it finishes.
>>>
>>> Gabe
>>>
>>> On Tue, Nov 2, 2021 at 4:36 AM Gabe Black 
>>> wrote:
>>>
 Attached is a log of a failing run, and backtrace of the segfault.

 Gabe

 On Tue, Nov 2, 2021 at 4:17 AM Gabe Black 
 wrote:

> Ok, I reproduced the segfault once, but then running again in gdb
> it exited normally. I'm pretty confident it's something to do with 
> things
> getting cleaned up and/or destructed at the end of the simulation, but
> until I catch something in the act of exploding I won't be able to 
> nail
> down specifically what's doing it.
>
> Gabe
>
> On Tue, Nov 2, 2021 at 3:46 AM Gabe Black 
> wrote:
>
>> A clean build seems to have fixed the IdeDisk problem.
>>
>> On Tue, Nov 2, 2021 at 3:35 AM Gabe Black 
>> wrote:
>>
>>> Can you get a backtrace from it? Or run it in valgrind? I'm
>>> trying to use the command line you provided locally, but it's 
>>> complaining
>>> about not being able to find IdeDisk which is very strange... I 
>>> don't think
>>> I have an account on the machine where this ran, but ideally I'll 
>>> be able
>>> to reproduce it locally where it will be easier to work with.
>>>
>>> Gabe
>>>
>>> On Mon, Nov 1, 2021 at 3:03 PM Jason Lowe-Power <
>>> ja...@lowepower.com> wrote:
>>>
 After spending some time on this, there is definitely a

[gem5-dev] Re: Build failed in Jenkins: nightly #27

2021-11-04 Thread Jason Lowe-Power via gem5-dev 
Hey Gabe,

Do these fix the nightly regression? If not, we may need to back out
"4fe56ff72 - (3 months ago) arch-arm,cpu: Replace rename modes with split
reg/elem register files." until we have a fix.

Cheers,
Jason

On Thu, Nov 4, 2021 at 12:13 AM Gabe Black  wrote:

> Valgrind hasn't finished, but what it found so far is attached. I went
> through it and have the following changes which should address these
> uninitialized accesses, and an inefficiency in the cache it found by
> accident.
>
> https://gem5-review.googlesource.com/c/public/gem5/+/52403
> https://gem5-review.googlesource.com/c/public/gem5/+/52404
> https://gem5-review.googlesource.com/c/public/gem5/+/52405
> https://gem5-review.googlesource.com/c/public/gem5/+/52406
>
> Gabe
>
> On Wed, Nov 3, 2021 at 12:45 PM Jason Lowe-Power 
> wrote:
>
>> Here's my data:
>>
>> BAD * 4fe56ff72 - (3 months ago) arch-arm,cpu: Replace rename modes with
>> split reg/elem register files. - Gabe Black
>> GOOD * 25138cbb7 - (4 weeks ago) arch: Simplify and tidy up PCState
>> classes. - Gabe Black
>> * 930986332 - (7 days ago) mem: Fix whitespace in
>> mem/ruby/system/Sequencer.py. - Gabe Black
>> GOOD * 69e6ea485 - (3 months ago) arch-arm: Add walkBits method to
>> PageTableOps - Giacomo Travaglini
>> * 1268c6ec3 - (2 weeks ago) arch-arm: Expose LookupLevel enum to the
>> python world - Giacomo Travaglini
>>
>> I've tested this a number of times and tested commits before and after
>> these commits. I have increasing confidence (though no certainty) that
>> 4fe56ff72 is the culprit.
>>
>> I'm running a UBSAN now to see if that will help at all.
>>
>> Cheers,
>> Jason
>>
>> On Tue, Nov 2, 2021 at 5:28 PM Gabe Black  wrote:
>>
>>> I'm going to kill it now, and restart it with --track-origins=yes and in
>>> a separate tree so I can keep working on other things while it runs.
>>>
>>> Gabe
>>>
>>> On Tue, Nov 2, 2021 at 5:11 PM Gabe Black  wrote:
>>>
 It's still running, but here's what it's found so far.

 Gabe

 On Tue, Nov 2, 2021 at 7:48 AM Jason Lowe-Power 
 wrote:

> Thanks! I tried a bisect but, tbh, it wasn't helpful since the error
> doesn't seem to be deterministic.
>
> As more evidence that it's a memory issue, the backtrace that I saw
> with GDB was something a bit different.
>
> Cheers,
> Jason
>
> On Tue, Nov 2, 2021 at 5:07 AM Gabe Black 
> wrote:
>
>> I'm running it under valgrind to see if that tells me anything, which
>> is going to take a while. I'll let you know if/when it finishes.
>>
>> Gabe
>>
>> On Tue, Nov 2, 2021 at 4:36 AM Gabe Black 
>> wrote:
>>
>>> Attached is a log of a failing run, and backtrace of the segfault.
>>>
>>> Gabe
>>>
>>> On Tue, Nov 2, 2021 at 4:17 AM Gabe Black 
>>> wrote:
>>>
 Ok, I reproduced the segfault once, but then running again in gdb
 it exited normally. I'm pretty confident it's something to do with 
 things
 getting cleaned up and/or destructed at the end of the simulation, but
 until I catch something in the act of exploding I won't be able to nail
 down specifically what's doing it.

 Gabe

 On Tue, Nov 2, 2021 at 3:46 AM Gabe Black 
 wrote:

> A clean build seems to have fixed the IdeDisk problem.
>
> On Tue, Nov 2, 2021 at 3:35 AM Gabe Black 
> wrote:
>
>> Can you get a backtrace from it? Or run it in valgrind? I'm
>> trying to use the command line you provided locally, but it's 
>> complaining
>> about not being able to find IdeDisk which is very strange... I 
>> don't think
>> I have an account on the machine where this ran, but ideally I'll be 
>> able
>> to reproduce it locally where it will be easier to work with.
>>
>> Gabe
>>
>> On Mon, Nov 1, 2021 at 3:03 PM Jason Lowe-Power <
>> ja...@lowepower.com> wrote:
>>
>>> After spending some time on this, there is definitely a segfault
>>> at the end of execution. It's odd that the testing scripts sometimes
>>> reports that it works.
>>>
>>> If you run the following, you should see a segfault at the end
>>> and no stats are generated:
>>> ../gem5/> build/ARM/gem5.opt tests/gem5/fs/linux/arm/run.py
>>> tests/gem5/configs/realview-o3.py tests/gem5/resources/arm .
>>>
>>> I also notice that when it doesn't fail the following is printed:
>>> "build/ARM/arch/arm/isa.hh:650: warn: User mode does not have
>>> SPSR
>>> build/ARM/arch/arm/isa.hh:650: warn: User mode does not have
>>> SPSR"
>>>
>>> But it's not printed when it fails.
>>>
>>> Cheers,
>>> Jason
>>>
>>> On Mon, Nov 1, 2021 at 8:29 AM Jason Lowe-Power <

[gem5-dev] Re: Build failed in Jenkins: nightly #27

2021-11-04 Thread Gabe Black via gem5-dev 
Valgrind hasn't finished, but what it found so far is attached. I went
through it and have the following changes which should address these
uninitialized accesses, and an inefficiency in the cache it found by
accident.

https://gem5-review.googlesource.com/c/public/gem5/+/52403
https://gem5-review.googlesource.com/c/public/gem5/+/52404
https://gem5-review.googlesource.com/c/public/gem5/+/52405
https://gem5-review.googlesource.com/c/public/gem5/+/52406

Gabe

On Wed, Nov 3, 2021 at 12:45 PM Jason Lowe-Power 
wrote:

> Here's my data:
>
> BAD * 4fe56ff72 - (3 months ago) arch-arm,cpu: Replace rename modes with
> split reg/elem register files. - Gabe Black
> GOOD * 25138cbb7 - (4 weeks ago) arch: Simplify and tidy up PCState
> classes. - Gabe Black
> * 930986332 - (7 days ago) mem: Fix whitespace in
> mem/ruby/system/Sequencer.py. - Gabe Black
> GOOD * 69e6ea485 - (3 months ago) arch-arm: Add walkBits method to
> PageTableOps - Giacomo Travaglini
> * 1268c6ec3 - (2 weeks ago) arch-arm: Expose LookupLevel enum to the
> python world - Giacomo Travaglini
>
> I've tested this a number of times and tested commits before and after
> these commits. I have increasing confidence (though no certainty) that
> 4fe56ff72 is the culprit.
>
> I'm running a UBSAN now to see if that will help at all.
>
> Cheers,
> Jason
>
> On Tue, Nov 2, 2021 at 5:28 PM Gabe Black  wrote:
>
>> I'm going to kill it now, and restart it with --track-origins=yes and in
>> a separate tree so I can keep working on other things while it runs.
>>
>> Gabe
>>
>> On Tue, Nov 2, 2021 at 5:11 PM Gabe Black  wrote:
>>
>>> It's still running, but here's what it's found so far.
>>>
>>> Gabe
>>>
>>> On Tue, Nov 2, 2021 at 7:48 AM Jason Lowe-Power 
>>> wrote:
>>>
 Thanks! I tried a bisect but, tbh, it wasn't helpful since the error
 doesn't seem to be deterministic.

 As more evidence that it's a memory issue, the backtrace that I saw
 with GDB was something a bit different.

 Cheers,
 Jason

 On Tue, Nov 2, 2021 at 5:07 AM Gabe Black  wrote:

> I'm running it under valgrind to see if that tells me anything, which
> is going to take a while. I'll let you know if/when it finishes.
>
> Gabe
>
> On Tue, Nov 2, 2021 at 4:36 AM Gabe Black 
> wrote:
>
>> Attached is a log of a failing run, and backtrace of the segfault.
>>
>> Gabe
>>
>> On Tue, Nov 2, 2021 at 4:17 AM Gabe Black 
>> wrote:
>>
>>> Ok, I reproduced the segfault once, but then running again in gdb it
>>> exited normally. I'm pretty confident it's something to do with things
>>> getting cleaned up and/or destructed at the end of the simulation, but
>>> until I catch something in the act of exploding I won't be able to nail
>>> down specifically what's doing it.
>>>
>>> Gabe
>>>
>>> On Tue, Nov 2, 2021 at 3:46 AM Gabe Black 
>>> wrote:
>>>
 A clean build seems to have fixed the IdeDisk problem.

 On Tue, Nov 2, 2021 at 3:35 AM Gabe Black 
 wrote:

> Can you get a backtrace from it? Or run it in valgrind? I'm trying
> to use the command line you provided locally, but it's complaining 
> about
> not being able to find IdeDisk which is very strange... I don't think 
> I
> have an account on the machine where this ran, but ideally I'll be 
> able to
> reproduce it locally where it will be easier to work with.
>
> Gabe
>
> On Mon, Nov 1, 2021 at 3:03 PM Jason Lowe-Power <
> ja...@lowepower.com> wrote:
>
>> After spending some time on this, there is definitely a segfault
>> at the end of execution. It's odd that the testing scripts sometimes
>> reports that it works.
>>
>> If you run the following, you should see a segfault at the end
>> and no stats are generated:
>> ../gem5/> build/ARM/gem5.opt tests/gem5/fs/linux/arm/run.py
>> tests/gem5/configs/realview-o3.py tests/gem5/resources/arm .
>>
>> I also notice that when it doesn't fail the following is printed:
>> "build/ARM/arch/arm/isa.hh:650: warn: User mode does not have SPSR
>> build/ARM/arch/arm/isa.hh:650: warn: User mode does not have SPSR"
>>
>> But it's not printed when it fails.
>>
>> Cheers,
>> Jason
>>
>> On Mon, Nov 1, 2021 at 8:29 AM Jason Lowe-Power <
>> ja...@lowepower.com> wrote:
>>
>>> I don't think so. The binaries haven't been updated since April
>>> ('aarch-system-20210904.tar.bz2'). Well, the blame says April even 
>>> if the
>>> filename is confusing (DDMM?).
>>>
>>> Here's the failure:
>>>

[gem5-dev] Re: Build failed in Jenkins: nightly #27

2021-11-03 Thread Jason Lowe-Power via gem5-dev 
Here's my data:

BAD * 4fe56ff72 - (3 months ago) arch-arm,cpu: Replace rename modes with
split reg/elem register files. - Gabe Black
GOOD * 25138cbb7 - (4 weeks ago) arch: Simplify and tidy up PCState
classes. - Gabe Black
* 930986332 - (7 days ago) mem: Fix whitespace in
mem/ruby/system/Sequencer.py. - Gabe Black
GOOD * 69e6ea485 - (3 months ago) arch-arm: Add walkBits method to
PageTableOps - Giacomo Travaglini
* 1268c6ec3 - (2 weeks ago) arch-arm: Expose LookupLevel enum to the python
world - Giacomo Travaglini

I've tested this a number of times and tested commits before and after
these commits. I have increasing confidence (though no certainty) that
4fe56ff72 is the culprit.

I'm running a UBSAN now to see if that will help at all.

Cheers,
Jason

On Tue, Nov 2, 2021 at 5:28 PM Gabe Black  wrote:

> I'm going to kill it now, and restart it with --track-origins=yes and in a
> separate tree so I can keep working on other things while it runs.
>
> Gabe
>
> On Tue, Nov 2, 2021 at 5:11 PM Gabe Black  wrote:
>
>> It's still running, but here's what it's found so far.
>>
>> Gabe
>>
>> On Tue, Nov 2, 2021 at 7:48 AM Jason Lowe-Power 
>> wrote:
>>
>>> Thanks! I tried a bisect but, tbh, it wasn't helpful since the error
>>> doesn't seem to be deterministic.
>>>
>>> As more evidence that it's a memory issue, the backtrace that I saw with
>>> GDB was something a bit different.
>>>
>>> Cheers,
>>> Jason
>>>
>>> On Tue, Nov 2, 2021 at 5:07 AM Gabe Black  wrote:
>>>
 I'm running it under valgrind to see if that tells me anything, which
 is going to take a while. I'll let you know if/when it finishes.

 Gabe

 On Tue, Nov 2, 2021 at 4:36 AM Gabe Black  wrote:

> Attached is a log of a failing run, and backtrace of the segfault.
>
> Gabe
>
> On Tue, Nov 2, 2021 at 4:17 AM Gabe Black 
> wrote:
>
>> Ok, I reproduced the segfault once, but then running again in gdb it
>> exited normally. I'm pretty confident it's something to do with things
>> getting cleaned up and/or destructed at the end of the simulation, but
>> until I catch something in the act of exploding I won't be able to nail
>> down specifically what's doing it.
>>
>> Gabe
>>
>> On Tue, Nov 2, 2021 at 3:46 AM Gabe Black 
>> wrote:
>>
>>> A clean build seems to have fixed the IdeDisk problem.
>>>
>>> On Tue, Nov 2, 2021 at 3:35 AM Gabe Black 
>>> wrote:
>>>
 Can you get a backtrace from it? Or run it in valgrind? I'm trying
 to use the command line you provided locally, but it's complaining 
 about
 not being able to find IdeDisk which is very strange... I don't think I
 have an account on the machine where this ran, but ideally I'll be 
 able to
 reproduce it locally where it will be easier to work with.

 Gabe

 On Mon, Nov 1, 2021 at 3:03 PM Jason Lowe-Power <
 ja...@lowepower.com> wrote:

> After spending some time on this, there is definitely a segfault
> at the end of execution. It's odd that the testing scripts sometimes
> reports that it works.
>
> If you run the following, you should see a segfault at the end and
> no stats are generated:
> ../gem5/> build/ARM/gem5.opt tests/gem5/fs/linux/arm/run.py
> tests/gem5/configs/realview-o3.py tests/gem5/resources/arm .
>
> I also notice that when it doesn't fail the following is printed:
> "build/ARM/arch/arm/isa.hh:650: warn: User mode does not have SPSR
> build/ARM/arch/arm/isa.hh:650: warn: User mode does not have SPSR"
>
> But it's not printed when it fails.
>
> Cheers,
> Jason
>
> On Mon, Nov 1, 2021 at 8:29 AM Jason Lowe-Power <
> ja...@lowepower.com> wrote:
>
>> I don't think so. The binaries haven't been updated since April
>> ('aarch-system-20210904.tar.bz2'). Well, the blame says April even 
>> if the
>> filename is confusing (DDMM?).
>>
>> Here's the failure:
>> https://jenkins.gem5.org/job/nightly/ws/tests/testing-results/SuiteUID%3Arealview-o3-ARM-x86_64-opt/TestUID%3Arealview-o3-ARM-x86_64-opt/simerr
>>
>> build/ARM/arch/arm/insts/pseudo.cc:173: warn: instruction 'csdb'
>> unimplemented
>> build/ARM/arch/arm/generated/decoder-ns.cc.inc:100643: warn:
>> instruction 'mcr bpiall' unimplemented
>> gem5 has encountered a segmentation fault!
>>
>> Cheers,
>> Jason
>>
>> On Sat, Oct 30, 2021 at 4:11 AM Gabe Black via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>>> Maybe you need to re-download the resources?
>>>
>>> Gabe
>>>
>>> On Sat, Oct 30, 2021 at 3:50 AM jenkins-no-reply--- via gem5-dev
>>>  wrote:

[gem5-dev] Re: Build failed in Jenkins: nightly #27

2021-11-02 Thread Jason Lowe-Power via gem5-dev 
Thanks! I tried a bisect but, tbh, it wasn't helpful since the error
doesn't seem to be deterministic.

As more evidence that it's a memory issue, the backtrace that I saw with
GDB was something a bit different.

Cheers,
Jason

On Tue, Nov 2, 2021 at 5:07 AM Gabe Black  wrote:

> I'm running it under valgrind to see if that tells me anything, which is
> going to take a while. I'll let you know if/when it finishes.
>
> Gabe
>
> On Tue, Nov 2, 2021 at 4:36 AM Gabe Black  wrote:
>
>> Attached is a log of a failing run, and backtrace of the segfault.
>>
>> Gabe
>>
>> On Tue, Nov 2, 2021 at 4:17 AM Gabe Black  wrote:
>>
>>> Ok, I reproduced the segfault once, but then running again in gdb it
>>> exited normally. I'm pretty confident it's something to do with things
>>> getting cleaned up and/or destructed at the end of the simulation, but
>>> until I catch something in the act of exploding I won't be able to nail
>>> down specifically what's doing it.
>>>
>>> Gabe
>>>
>>> On Tue, Nov 2, 2021 at 3:46 AM Gabe Black  wrote:
>>>
 A clean build seems to have fixed the IdeDisk problem.

 On Tue, Nov 2, 2021 at 3:35 AM Gabe Black  wrote:

> Can you get a backtrace from it? Or run it in valgrind? I'm trying to
> use the command line you provided locally, but it's complaining about not
> being able to find IdeDisk which is very strange... I don't think I have 
> an
> account on the machine where this ran, but ideally I'll be able to
> reproduce it locally where it will be easier to work with.
>
> Gabe
>
> On Mon, Nov 1, 2021 at 3:03 PM Jason Lowe-Power 
> wrote:
>
>> After spending some time on this, there is definitely a segfault at
>> the end of execution. It's odd that the testing scripts sometimes reports
>> that it works.
>>
>> If you run the following, you should see a segfault at the end and no
>> stats are generated:
>> ../gem5/> build/ARM/gem5.opt tests/gem5/fs/linux/arm/run.py
>> tests/gem5/configs/realview-o3.py tests/gem5/resources/arm .
>>
>> I also notice that when it doesn't fail the following is printed:
>> "build/ARM/arch/arm/isa.hh:650: warn: User mode does not have SPSR
>> build/ARM/arch/arm/isa.hh:650: warn: User mode does not have SPSR"
>>
>> But it's not printed when it fails.
>>
>> Cheers,
>> Jason
>>
>> On Mon, Nov 1, 2021 at 8:29 AM Jason Lowe-Power 
>> wrote:
>>
>>> I don't think so. The binaries haven't been updated since April
>>> ('aarch-system-20210904.tar.bz2'). Well, the blame says April even if 
>>> the
>>> filename is confusing (DDMM?).
>>>
>>> Here's the failure:
>>> https://jenkins.gem5.org/job/nightly/ws/tests/testing-results/SuiteUID%3Arealview-o3-ARM-x86_64-opt/TestUID%3Arealview-o3-ARM-x86_64-opt/simerr
>>>
>>> build/ARM/arch/arm/insts/pseudo.cc:173: warn: instruction 'csdb'
>>> unimplemented
>>> build/ARM/arch/arm/generated/decoder-ns.cc.inc:100643: warn:
>>> instruction 'mcr bpiall' unimplemented
>>> gem5 has encountered a segmentation fault!
>>>
>>> Cheers,
>>> Jason
>>>
>>> On Sat, Oct 30, 2021 at 4:11 AM Gabe Black via gem5-dev <
>>> gem5-dev@gem5.org> wrote:
>>>
 Maybe you need to re-download the resources?

 Gabe

 On Sat, Oct 30, 2021 at 3:50 AM jenkins-no-reply--- via gem5-dev <
 gem5-dev@gem5.org> wrote:

> See 
>
> Changes:
>
>
> --
> [...truncated 809.58 KB...]
> [--] 4 tests from CheckpointInFixture
> [ RUN  ] CheckpointInFixture.FindSections
> [   OK ] CheckpointInFixture.FindSections (1 ms)
> [ RUN  ] CheckpointInFixture.FindEntries
> [   OK ] CheckpointInFixture.FindEntries (0 ms)
> [ RUN  ] CheckpointInFixture.ExtractEntries
> [   OK ] CheckpointInFixture.ExtractEntries (0 ms)
> [ RUN  ] CheckpointInFixture.SCSCptInPathScoped
> [   OK ] CheckpointInFixture.SCSCptInPathScoped (0 ms)
> [--] 4 tests from CheckpointInFixture (1 ms total)
>
> [--] 6 tests from SerializableFixture
> [ RUN  ] SerializableFixture.SCSChangeCptOutSingle
> [   OK ] SerializableFixture.SCSChangeCptOutSingle (0 ms)
> [ RUN  ] SerializableFixture.SCSChangeCptOutMultiple
> [   OK ] SerializableFixture.SCSChangeCptOutMultiple (1 ms)
> [ RUN  ] SerializableFixture.SCSChangeCptOutLarge
> [   OK ] SerializableFixture.SCSChangeCptOutLarge (0 ms)
> [ RUN  ] SerializableFixture.SectionSerializationSimple
> [   OK ] SerializableFixture.SectionSerializationSimple (0 ms)
> [ RUN  ] SerializableFixture.ParamOutIn

[gem5-dev] Re: Build failed in Jenkins: nightly #27

2021-11-02 Thread Gabe Black via gem5-dev 
I'm running it under valgrind to see if that tells me anything, which is
going to take a while. I'll let you know if/when it finishes.

Gabe

On Tue, Nov 2, 2021 at 4:36 AM Gabe Black  wrote:

> Attached is a log of a failing run, and backtrace of the segfault.
>
> Gabe
>
> On Tue, Nov 2, 2021 at 4:17 AM Gabe Black  wrote:
>
>> Ok, I reproduced the segfault once, but then running again in gdb it
>> exited normally. I'm pretty confident it's something to do with things
>> getting cleaned up and/or destructed at the end of the simulation, but
>> until I catch something in the act of exploding I won't be able to nail
>> down specifically what's doing it.
>>
>> Gabe
>>
>> On Tue, Nov 2, 2021 at 3:46 AM Gabe Black  wrote:
>>
>>> A clean build seems to have fixed the IdeDisk problem.
>>>
>>> On Tue, Nov 2, 2021 at 3:35 AM Gabe Black  wrote:
>>>
 Can you get a backtrace from it? Or run it in valgrind? I'm trying to
 use the command line you provided locally, but it's complaining about not
 being able to find IdeDisk which is very strange... I don't think I have an
 account on the machine where this ran, but ideally I'll be able to
 reproduce it locally where it will be easier to work with.

 Gabe

 On Mon, Nov 1, 2021 at 3:03 PM Jason Lowe-Power 
 wrote:

> After spending some time on this, there is definitely a segfault at
> the end of execution. It's odd that the testing scripts sometimes reports
> that it works.
>
> If you run the following, you should see a segfault at the end and no
> stats are generated:
> ../gem5/> build/ARM/gem5.opt tests/gem5/fs/linux/arm/run.py
> tests/gem5/configs/realview-o3.py tests/gem5/resources/arm .
>
> I also notice that when it doesn't fail the following is printed:
> "build/ARM/arch/arm/isa.hh:650: warn: User mode does not have SPSR
> build/ARM/arch/arm/isa.hh:650: warn: User mode does not have SPSR"
>
> But it's not printed when it fails.
>
> Cheers,
> Jason
>
> On Mon, Nov 1, 2021 at 8:29 AM Jason Lowe-Power 
> wrote:
>
>> I don't think so. The binaries haven't been updated since April
>> ('aarch-system-20210904.tar.bz2'). Well, the blame says April even if the
>> filename is confusing (DDMM?).
>>
>> Here's the failure:
>> https://jenkins.gem5.org/job/nightly/ws/tests/testing-results/SuiteUID%3Arealview-o3-ARM-x86_64-opt/TestUID%3Arealview-o3-ARM-x86_64-opt/simerr
>>
>> build/ARM/arch/arm/insts/pseudo.cc:173: warn: instruction 'csdb'
>> unimplemented
>> build/ARM/arch/arm/generated/decoder-ns.cc.inc:100643: warn:
>> instruction 'mcr bpiall' unimplemented
>> gem5 has encountered a segmentation fault!
>>
>> Cheers,
>> Jason
>>
>> On Sat, Oct 30, 2021 at 4:11 AM Gabe Black via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>>> Maybe you need to re-download the resources?
>>>
>>> Gabe
>>>
>>> On Sat, Oct 30, 2021 at 3:50 AM jenkins-no-reply--- via gem5-dev <
>>> gem5-dev@gem5.org> wrote:
>>>
 See 

 Changes:


 --
 [...truncated 809.58 KB...]
 [--] 4 tests from CheckpointInFixture
 [ RUN  ] CheckpointInFixture.FindSections
 [   OK ] CheckpointInFixture.FindSections (1 ms)
 [ RUN  ] CheckpointInFixture.FindEntries
 [   OK ] CheckpointInFixture.FindEntries (0 ms)
 [ RUN  ] CheckpointInFixture.ExtractEntries
 [   OK ] CheckpointInFixture.ExtractEntries (0 ms)
 [ RUN  ] CheckpointInFixture.SCSCptInPathScoped
 [   OK ] CheckpointInFixture.SCSCptInPathScoped (0 ms)
 [--] 4 tests from CheckpointInFixture (1 ms total)

 [--] 6 tests from SerializableFixture
 [ RUN  ] SerializableFixture.SCSChangeCptOutSingle
 [   OK ] SerializableFixture.SCSChangeCptOutSingle (0 ms)
 [ RUN  ] SerializableFixture.SCSChangeCptOutMultiple
 [   OK ] SerializableFixture.SCSChangeCptOutMultiple (1 ms)
 [ RUN  ] SerializableFixture.SCSChangeCptOutLarge
 [   OK ] SerializableFixture.SCSChangeCptOutLarge (0 ms)
 [ RUN  ] SerializableFixture.SectionSerializationSimple
 [   OK ] SerializableFixture.SectionSerializationSimple (0 ms)
 [ RUN  ] SerializableFixture.ParamOutIn
 [   OK ] SerializableFixture.ParamOutIn (0 ms)
 [ RUN  ] SerializableFixture.ParamOutInMultipleSections
 [   OK ] SerializableFixture.ParamOutInMultipleSections (0 ms)
 [--] 6 tests from SerializableFixture (2 ms total)

 [--] Global test environment tear-down
 [==] 33 tests from 8 test suites ran. (171 ms total)

[gem5-dev] Re: Build failed in Jenkins: nightly #27

2021-11-02 Thread Gabe Black via gem5-dev 
Attached is a log of a failing run, and backtrace of the segfault.

Gabe

On Tue, Nov 2, 2021 at 4:17 AM Gabe Black  wrote:

> Ok, I reproduced the segfault once, but then running again in gdb it
> exited normally. I'm pretty confident it's something to do with things
> getting cleaned up and/or destructed at the end of the simulation, but
> until I catch something in the act of exploding I won't be able to nail
> down specifically what's doing it.
>
> Gabe
>
> On Tue, Nov 2, 2021 at 3:46 AM Gabe Black  wrote:
>
>> A clean build seems to have fixed the IdeDisk problem.
>>
>> On Tue, Nov 2, 2021 at 3:35 AM Gabe Black  wrote:
>>
>>> Can you get a backtrace from it? Or run it in valgrind? I'm trying to
>>> use the command line you provided locally, but it's complaining about not
>>> being able to find IdeDisk which is very strange... I don't think I have an
>>> account on the machine where this ran, but ideally I'll be able to
>>> reproduce it locally where it will be easier to work with.
>>>
>>> Gabe
>>>
>>> On Mon, Nov 1, 2021 at 3:03 PM Jason Lowe-Power 
>>> wrote:
>>>
 After spending some time on this, there is definitely a segfault at the
 end of execution. It's odd that the testing scripts sometimes reports that
 it works.

 If you run the following, you should see a segfault at the end and no
 stats are generated:
 ../gem5/> build/ARM/gem5.opt tests/gem5/fs/linux/arm/run.py
 tests/gem5/configs/realview-o3.py tests/gem5/resources/arm .

 I also notice that when it doesn't fail the following is printed:
 "build/ARM/arch/arm/isa.hh:650: warn: User mode does not have SPSR
 build/ARM/arch/arm/isa.hh:650: warn: User mode does not have SPSR"

 But it's not printed when it fails.

 Cheers,
 Jason

 On Mon, Nov 1, 2021 at 8:29 AM Jason Lowe-Power 
 wrote:

> I don't think so. The binaries haven't been updated since April
> ('aarch-system-20210904.tar.bz2'). Well, the blame says April even if the
> filename is confusing (DDMM?).
>
> Here's the failure:
> https://jenkins.gem5.org/job/nightly/ws/tests/testing-results/SuiteUID%3Arealview-o3-ARM-x86_64-opt/TestUID%3Arealview-o3-ARM-x86_64-opt/simerr
>
> build/ARM/arch/arm/insts/pseudo.cc:173: warn: instruction 'csdb'
> unimplemented
> build/ARM/arch/arm/generated/decoder-ns.cc.inc:100643: warn:
> instruction 'mcr bpiall' unimplemented
> gem5 has encountered a segmentation fault!
>
> Cheers,
> Jason
>
> On Sat, Oct 30, 2021 at 4:11 AM Gabe Black via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> Maybe you need to re-download the resources?
>>
>> Gabe
>>
>> On Sat, Oct 30, 2021 at 3:50 AM jenkins-no-reply--- via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>>> See 
>>>
>>> Changes:
>>>
>>>
>>> --
>>> [...truncated 809.58 KB...]
>>> [--] 4 tests from CheckpointInFixture
>>> [ RUN  ] CheckpointInFixture.FindSections
>>> [   OK ] CheckpointInFixture.FindSections (1 ms)
>>> [ RUN  ] CheckpointInFixture.FindEntries
>>> [   OK ] CheckpointInFixture.FindEntries (0 ms)
>>> [ RUN  ] CheckpointInFixture.ExtractEntries
>>> [   OK ] CheckpointInFixture.ExtractEntries (0 ms)
>>> [ RUN  ] CheckpointInFixture.SCSCptInPathScoped
>>> [   OK ] CheckpointInFixture.SCSCptInPathScoped (0 ms)
>>> [--] 4 tests from CheckpointInFixture (1 ms total)
>>>
>>> [--] 6 tests from SerializableFixture
>>> [ RUN  ] SerializableFixture.SCSChangeCptOutSingle
>>> [   OK ] SerializableFixture.SCSChangeCptOutSingle (0 ms)
>>> [ RUN  ] SerializableFixture.SCSChangeCptOutMultiple
>>> [   OK ] SerializableFixture.SCSChangeCptOutMultiple (1 ms)
>>> [ RUN  ] SerializableFixture.SCSChangeCptOutLarge
>>> [   OK ] SerializableFixture.SCSChangeCptOutLarge (0 ms)
>>> [ RUN  ] SerializableFixture.SectionSerializationSimple
>>> [   OK ] SerializableFixture.SectionSerializationSimple (0 ms)
>>> [ RUN  ] SerializableFixture.ParamOutIn
>>> [   OK ] SerializableFixture.ParamOutIn (0 ms)
>>> [ RUN  ] SerializableFixture.ParamOutInMultipleSections
>>> [   OK ] SerializableFixture.ParamOutInMultipleSections (0 ms)
>>> [--] 6 tests from SerializableFixture (2 ms total)
>>>
>>> [--] Global test environment tear-down
>>> [==] 33 tests from 8 test suites ran. (171 ms total)
>>> [  PASSED  ] 33 tests.
>>>
>>>   YOU HAVE 1 DISABLED TEST
>>>
>>> [   OK ] LoggingDeathTest.PanicLoggerExitHelper (149 ms)
>>> [ RUN  ] LoggingDeathTest.ExitMessage
>>> [   OK ] LoggingDeathTest.ExitMessage (152 ms)
>>> [ RUN  ] LoggingDeathTest.Panic
>>> [

[gem5-dev] Re: Build failed in Jenkins: nightly #27

2021-11-02 Thread Gabe Black via gem5-dev 
Ok, I reproduced the segfault once, but then running again in gdb it exited
normally. I'm pretty confident it's something to do with things getting
cleaned up and/or destructed at the end of the simulation, but until I
catch something in the act of exploding I won't be able to nail down
specifically what's doing it.

Gabe

On Tue, Nov 2, 2021 at 3:46 AM Gabe Black  wrote:

> A clean build seems to have fixed the IdeDisk problem.
>
> On Tue, Nov 2, 2021 at 3:35 AM Gabe Black  wrote:
>
>> Can you get a backtrace from it? Or run it in valgrind? I'm trying to use
>> the command line you provided locally, but it's complaining about not being
>> able to find IdeDisk which is very strange... I don't think I have an
>> account on the machine where this ran, but ideally I'll be able to
>> reproduce it locally where it will be easier to work with.
>>
>> Gabe
>>
>> On Mon, Nov 1, 2021 at 3:03 PM Jason Lowe-Power 
>> wrote:
>>
>>> After spending some time on this, there is definitely a segfault at the
>>> end of execution. It's odd that the testing scripts sometimes reports that
>>> it works.
>>>
>>> If you run the following, you should see a segfault at the end and no
>>> stats are generated:
>>> ../gem5/> build/ARM/gem5.opt tests/gem5/fs/linux/arm/run.py
>>> tests/gem5/configs/realview-o3.py tests/gem5/resources/arm .
>>>
>>> I also notice that when it doesn't fail the following is printed:
>>> "build/ARM/arch/arm/isa.hh:650: warn: User mode does not have SPSR
>>> build/ARM/arch/arm/isa.hh:650: warn: User mode does not have SPSR"
>>>
>>> But it's not printed when it fails.
>>>
>>> Cheers,
>>> Jason
>>>
>>> On Mon, Nov 1, 2021 at 8:29 AM Jason Lowe-Power 
>>> wrote:
>>>
 I don't think so. The binaries haven't been updated since April
 ('aarch-system-20210904.tar.bz2'). Well, the blame says April even if the
 filename is confusing (DDMM?).

 Here's the failure:
 https://jenkins.gem5.org/job/nightly/ws/tests/testing-results/SuiteUID%3Arealview-o3-ARM-x86_64-opt/TestUID%3Arealview-o3-ARM-x86_64-opt/simerr

 build/ARM/arch/arm/insts/pseudo.cc:173: warn: instruction 'csdb'
 unimplemented
 build/ARM/arch/arm/generated/decoder-ns.cc.inc:100643: warn:
 instruction 'mcr bpiall' unimplemented
 gem5 has encountered a segmentation fault!

 Cheers,
 Jason

 On Sat, Oct 30, 2021 at 4:11 AM Gabe Black via gem5-dev <
 gem5-dev@gem5.org> wrote:

> Maybe you need to re-download the resources?
>
> Gabe
>
> On Sat, Oct 30, 2021 at 3:50 AM jenkins-no-reply--- via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> See 
>>
>> Changes:
>>
>>
>> --
>> [...truncated 809.58 KB...]
>> [--] 4 tests from CheckpointInFixture
>> [ RUN  ] CheckpointInFixture.FindSections
>> [   OK ] CheckpointInFixture.FindSections (1 ms)
>> [ RUN  ] CheckpointInFixture.FindEntries
>> [   OK ] CheckpointInFixture.FindEntries (0 ms)
>> [ RUN  ] CheckpointInFixture.ExtractEntries
>> [   OK ] CheckpointInFixture.ExtractEntries (0 ms)
>> [ RUN  ] CheckpointInFixture.SCSCptInPathScoped
>> [   OK ] CheckpointInFixture.SCSCptInPathScoped (0 ms)
>> [--] 4 tests from CheckpointInFixture (1 ms total)
>>
>> [--] 6 tests from SerializableFixture
>> [ RUN  ] SerializableFixture.SCSChangeCptOutSingle
>> [   OK ] SerializableFixture.SCSChangeCptOutSingle (0 ms)
>> [ RUN  ] SerializableFixture.SCSChangeCptOutMultiple
>> [   OK ] SerializableFixture.SCSChangeCptOutMultiple (1 ms)
>> [ RUN  ] SerializableFixture.SCSChangeCptOutLarge
>> [   OK ] SerializableFixture.SCSChangeCptOutLarge (0 ms)
>> [ RUN  ] SerializableFixture.SectionSerializationSimple
>> [   OK ] SerializableFixture.SectionSerializationSimple (0 ms)
>> [ RUN  ] SerializableFixture.ParamOutIn
>> [   OK ] SerializableFixture.ParamOutIn (0 ms)
>> [ RUN  ] SerializableFixture.ParamOutInMultipleSections
>> [   OK ] SerializableFixture.ParamOutInMultipleSections (0 ms)
>> [--] 6 tests from SerializableFixture (2 ms total)
>>
>> [--] Global test environment tear-down
>> [==] 33 tests from 8 test suites ran. (171 ms total)
>> [  PASSED  ] 33 tests.
>>
>>   YOU HAVE 1 DISABLED TEST
>>
>> [   OK ] LoggingDeathTest.PanicLoggerExitHelper (149 ms)
>> [ RUN  ] LoggingDeathTest.ExitMessage
>> [   OK ] LoggingDeathTest.ExitMessage (152 ms)
>> [ RUN  ] LoggingDeathTest.Panic
>> [   OK ] LoggingDeathTest.Panic (151 ms)
>> [ RUN  ] LoggingDeathTest.Fatal
>> [   OK ] LoggingDeathTest.Fatal (2 ms)
>> [ RUN  ] LoggingDeathTest.PanicIf
>> [   OK ] LoggingDeathTest.PanicIf (150 ms)
>> [ RUN

[gem5-dev] Re: Build failed in Jenkins: nightly #27

2021-11-02 Thread Gabe Black via gem5-dev 
A clean build seems to have fixed the IdeDisk problem.

On Tue, Nov 2, 2021 at 3:35 AM Gabe Black  wrote:

> Can you get a backtrace from it? Or run it in valgrind? I'm trying to use
> the command line you provided locally, but it's complaining about not being
> able to find IdeDisk which is very strange... I don't think I have an
> account on the machine where this ran, but ideally I'll be able to
> reproduce it locally where it will be easier to work with.
>
> Gabe
>
> On Mon, Nov 1, 2021 at 3:03 PM Jason Lowe-Power 
> wrote:
>
>> After spending some time on this, there is definitely a segfault at the
>> end of execution. It's odd that the testing scripts sometimes reports that
>> it works.
>>
>> If you run the following, you should see a segfault at the end and no
>> stats are generated:
>> ../gem5/> build/ARM/gem5.opt tests/gem5/fs/linux/arm/run.py
>> tests/gem5/configs/realview-o3.py tests/gem5/resources/arm .
>>
>> I also notice that when it doesn't fail the following is printed:
>> "build/ARM/arch/arm/isa.hh:650: warn: User mode does not have SPSR
>> build/ARM/arch/arm/isa.hh:650: warn: User mode does not have SPSR"
>>
>> But it's not printed when it fails.
>>
>> Cheers,
>> Jason
>>
>> On Mon, Nov 1, 2021 at 8:29 AM Jason Lowe-Power 
>> wrote:
>>
>>> I don't think so. The binaries haven't been updated since April
>>> ('aarch-system-20210904.tar.bz2'). Well, the blame says April even if the
>>> filename is confusing (DDMM?).
>>>
>>> Here's the failure:
>>> https://jenkins.gem5.org/job/nightly/ws/tests/testing-results/SuiteUID%3Arealview-o3-ARM-x86_64-opt/TestUID%3Arealview-o3-ARM-x86_64-opt/simerr
>>>
>>> build/ARM/arch/arm/insts/pseudo.cc:173: warn: instruction 'csdb'
>>> unimplemented
>>> build/ARM/arch/arm/generated/decoder-ns.cc.inc:100643: warn: instruction
>>> 'mcr bpiall' unimplemented
>>> gem5 has encountered a segmentation fault!
>>>
>>> Cheers,
>>> Jason
>>>
>>> On Sat, Oct 30, 2021 at 4:11 AM Gabe Black via gem5-dev <
>>> gem5-dev@gem5.org> wrote:
>>>
 Maybe you need to re-download the resources?

 Gabe

 On Sat, Oct 30, 2021 at 3:50 AM jenkins-no-reply--- via gem5-dev <
 gem5-dev@gem5.org> wrote:

> See 
>
> Changes:
>
>
> --
> [...truncated 809.58 KB...]
> [--] 4 tests from CheckpointInFixture
> [ RUN  ] CheckpointInFixture.FindSections
> [   OK ] CheckpointInFixture.FindSections (1 ms)
> [ RUN  ] CheckpointInFixture.FindEntries
> [   OK ] CheckpointInFixture.FindEntries (0 ms)
> [ RUN  ] CheckpointInFixture.ExtractEntries
> [   OK ] CheckpointInFixture.ExtractEntries (0 ms)
> [ RUN  ] CheckpointInFixture.SCSCptInPathScoped
> [   OK ] CheckpointInFixture.SCSCptInPathScoped (0 ms)
> [--] 4 tests from CheckpointInFixture (1 ms total)
>
> [--] 6 tests from SerializableFixture
> [ RUN  ] SerializableFixture.SCSChangeCptOutSingle
> [   OK ] SerializableFixture.SCSChangeCptOutSingle (0 ms)
> [ RUN  ] SerializableFixture.SCSChangeCptOutMultiple
> [   OK ] SerializableFixture.SCSChangeCptOutMultiple (1 ms)
> [ RUN  ] SerializableFixture.SCSChangeCptOutLarge
> [   OK ] SerializableFixture.SCSChangeCptOutLarge (0 ms)
> [ RUN  ] SerializableFixture.SectionSerializationSimple
> [   OK ] SerializableFixture.SectionSerializationSimple (0 ms)
> [ RUN  ] SerializableFixture.ParamOutIn
> [   OK ] SerializableFixture.ParamOutIn (0 ms)
> [ RUN  ] SerializableFixture.ParamOutInMultipleSections
> [   OK ] SerializableFixture.ParamOutInMultipleSections (0 ms)
> [--] 6 tests from SerializableFixture (2 ms total)
>
> [--] Global test environment tear-down
> [==] 33 tests from 8 test suites ran. (171 ms total)
> [  PASSED  ] 33 tests.
>
>   YOU HAVE 1 DISABLED TEST
>
> [   OK ] LoggingDeathTest.PanicLoggerExitHelper (149 ms)
> [ RUN  ] LoggingDeathTest.ExitMessage
> [   OK ] LoggingDeathTest.ExitMessage (152 ms)
> [ RUN  ] LoggingDeathTest.Panic
> [   OK ] LoggingDeathTest.Panic (151 ms)
> [ RUN  ] LoggingDeathTest.Fatal
> [   OK ] LoggingDeathTest.Fatal (2 ms)
> [ RUN  ] LoggingDeathTest.PanicIf
> [   OK ] LoggingDeathTest.PanicIf (150 ms)
> [ RUN  ] LoggingDeathTest.FatalIf
> [   OK ] LoggingDeathTest.FatalIf (3 ms)
> [ RUN  ] LoggingDeathTest.gem5Assert
> [  SKIPPED ] LoggingDeathTest.gem5Assert (0 ms)
> [--] 13 tests from LoggingDeathTest (1216 ms total)
>
> [--] 21 tests from LoggingFixture
> [ RUN  ] LoggingFixture.BasicPrint
> [   OK ] LoggingFixture.BasicPrint (0 ms)
> [ RUN  ] LoggingFixture.VariadicCharPrint
> [   OK ]

[gem5-dev] Re: Build failed in Jenkins: nightly #27

2021-11-02 Thread Gabe Black via gem5-dev 
Can you get a backtrace from it? Or run it in valgrind? I'm trying to use
the command line you provided locally, but it's complaining about not being
able to find IdeDisk which is very strange... I don't think I have an
account on the machine where this ran, but ideally I'll be able to
reproduce it locally where it will be easier to work with.

Gabe

On Mon, Nov 1, 2021 at 3:03 PM Jason Lowe-Power  wrote:

> After spending some time on this, there is definitely a segfault at the
> end of execution. It's odd that the testing scripts sometimes reports that
> it works.
>
> If you run the following, you should see a segfault at the end and no
> stats are generated:
> ../gem5/> build/ARM/gem5.opt tests/gem5/fs/linux/arm/run.py
> tests/gem5/configs/realview-o3.py tests/gem5/resources/arm .
>
> I also notice that when it doesn't fail the following is printed:
> "build/ARM/arch/arm/isa.hh:650: warn: User mode does not have SPSR
> build/ARM/arch/arm/isa.hh:650: warn: User mode does not have SPSR"
>
> But it's not printed when it fails.
>
> Cheers,
> Jason
>
> On Mon, Nov 1, 2021 at 8:29 AM Jason Lowe-Power 
> wrote:
>
>> I don't think so. The binaries haven't been updated since April
>> ('aarch-system-20210904.tar.bz2'). Well, the blame says April even if the
>> filename is confusing (DDMM?).
>>
>> Here's the failure:
>> https://jenkins.gem5.org/job/nightly/ws/tests/testing-results/SuiteUID%3Arealview-o3-ARM-x86_64-opt/TestUID%3Arealview-o3-ARM-x86_64-opt/simerr
>>
>> build/ARM/arch/arm/insts/pseudo.cc:173: warn: instruction 'csdb'
>> unimplemented
>> build/ARM/arch/arm/generated/decoder-ns.cc.inc:100643: warn: instruction
>> 'mcr bpiall' unimplemented
>> gem5 has encountered a segmentation fault!
>>
>> Cheers,
>> Jason
>>
>> On Sat, Oct 30, 2021 at 4:11 AM Gabe Black via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>>> Maybe you need to re-download the resources?
>>>
>>> Gabe
>>>
>>> On Sat, Oct 30, 2021 at 3:50 AM jenkins-no-reply--- via gem5-dev <
>>> gem5-dev@gem5.org> wrote:
>>>
 See 

 Changes:


 --
 [...truncated 809.58 KB...]
 [--] 4 tests from CheckpointInFixture
 [ RUN  ] CheckpointInFixture.FindSections
 [   OK ] CheckpointInFixture.FindSections (1 ms)
 [ RUN  ] CheckpointInFixture.FindEntries
 [   OK ] CheckpointInFixture.FindEntries (0 ms)
 [ RUN  ] CheckpointInFixture.ExtractEntries
 [   OK ] CheckpointInFixture.ExtractEntries (0 ms)
 [ RUN  ] CheckpointInFixture.SCSCptInPathScoped
 [   OK ] CheckpointInFixture.SCSCptInPathScoped (0 ms)
 [--] 4 tests from CheckpointInFixture (1 ms total)

 [--] 6 tests from SerializableFixture
 [ RUN  ] SerializableFixture.SCSChangeCptOutSingle
 [   OK ] SerializableFixture.SCSChangeCptOutSingle (0 ms)
 [ RUN  ] SerializableFixture.SCSChangeCptOutMultiple
 [   OK ] SerializableFixture.SCSChangeCptOutMultiple (1 ms)
 [ RUN  ] SerializableFixture.SCSChangeCptOutLarge
 [   OK ] SerializableFixture.SCSChangeCptOutLarge (0 ms)
 [ RUN  ] SerializableFixture.SectionSerializationSimple
 [   OK ] SerializableFixture.SectionSerializationSimple (0 ms)
 [ RUN  ] SerializableFixture.ParamOutIn
 [   OK ] SerializableFixture.ParamOutIn (0 ms)
 [ RUN  ] SerializableFixture.ParamOutInMultipleSections
 [   OK ] SerializableFixture.ParamOutInMultipleSections (0 ms)
 [--] 6 tests from SerializableFixture (2 ms total)

 [--] Global test environment tear-down
 [==] 33 tests from 8 test suites ran. (171 ms total)
 [  PASSED  ] 33 tests.

   YOU HAVE 1 DISABLED TEST

 [   OK ] LoggingDeathTest.PanicLoggerExitHelper (149 ms)
 [ RUN  ] LoggingDeathTest.ExitMessage
 [   OK ] LoggingDeathTest.ExitMessage (152 ms)
 [ RUN  ] LoggingDeathTest.Panic
 [   OK ] LoggingDeathTest.Panic (151 ms)
 [ RUN  ] LoggingDeathTest.Fatal
 [   OK ] LoggingDeathTest.Fatal (2 ms)
 [ RUN  ] LoggingDeathTest.PanicIf
 [   OK ] LoggingDeathTest.PanicIf (150 ms)
 [ RUN  ] LoggingDeathTest.FatalIf
 [   OK ] LoggingDeathTest.FatalIf (3 ms)
 [ RUN  ] LoggingDeathTest.gem5Assert
 [  SKIPPED ] LoggingDeathTest.gem5Assert (0 ms)
 [--] 13 tests from LoggingDeathTest (1216 ms total)

 [--] 21 tests from LoggingFixture
 [ RUN  ] LoggingFixture.BasicPrint
 [   OK ] LoggingFixture.BasicPrint (0 ms)
 [ RUN  ] LoggingFixture.VariadicCharPrint
 [   OK ] LoggingFixture.VariadicCharPrint (0 ms)
 [ RUN  ] LoggingFixture.VariadicStringPrint
 [   OK ] LoggingFixture.VariadicStringPrint (0 ms)
 [ RUN  ] LoggingFixture.VariadicCharMissingPrint
 [   OK ]

[gem5-dev] Re: Build failed in Jenkins: nightly #27

2021-11-01 Thread Jason Lowe-Power via gem5-dev 
After spending some time on this, there is definitely a segfault at the end
of execution. It's odd that the testing scripts sometimes reports that it
works.

If you run the following, you should see a segfault at the end and no stats
are generated:
../gem5/> build/ARM/gem5.opt tests/gem5/fs/linux/arm/run.py
tests/gem5/configs/realview-o3.py tests/gem5/resources/arm .

I also notice that when it doesn't fail the following is printed:
"build/ARM/arch/arm/isa.hh:650: warn: User mode does not have SPSR
build/ARM/arch/arm/isa.hh:650: warn: User mode does not have SPSR"

But it's not printed when it fails.

Cheers,
Jason

On Mon, Nov 1, 2021 at 8:29 AM Jason Lowe-Power  wrote:

> I don't think so. The binaries haven't been updated since April
> ('aarch-system-20210904.tar.bz2'). Well, the blame says April even if the
> filename is confusing (DDMM?).
>
> Here's the failure:
> https://jenkins.gem5.org/job/nightly/ws/tests/testing-results/SuiteUID%3Arealview-o3-ARM-x86_64-opt/TestUID%3Arealview-o3-ARM-x86_64-opt/simerr
>
> build/ARM/arch/arm/insts/pseudo.cc:173: warn: instruction 'csdb'
> unimplemented
> build/ARM/arch/arm/generated/decoder-ns.cc.inc:100643: warn: instruction
> 'mcr bpiall' unimplemented
> gem5 has encountered a segmentation fault!
>
> Cheers,
> Jason
>
> On Sat, Oct 30, 2021 at 4:11 AM Gabe Black via gem5-dev 
> wrote:
>
>> Maybe you need to re-download the resources?
>>
>> Gabe
>>
>> On Sat, Oct 30, 2021 at 3:50 AM jenkins-no-reply--- via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>>> See 
>>>
>>> Changes:
>>>
>>>
>>> --
>>> [...truncated 809.58 KB...]
>>> [--] 4 tests from CheckpointInFixture
>>> [ RUN  ] CheckpointInFixture.FindSections
>>> [   OK ] CheckpointInFixture.FindSections (1 ms)
>>> [ RUN  ] CheckpointInFixture.FindEntries
>>> [   OK ] CheckpointInFixture.FindEntries (0 ms)
>>> [ RUN  ] CheckpointInFixture.ExtractEntries
>>> [   OK ] CheckpointInFixture.ExtractEntries (0 ms)
>>> [ RUN  ] CheckpointInFixture.SCSCptInPathScoped
>>> [   OK ] CheckpointInFixture.SCSCptInPathScoped (0 ms)
>>> [--] 4 tests from CheckpointInFixture (1 ms total)
>>>
>>> [--] 6 tests from SerializableFixture
>>> [ RUN  ] SerializableFixture.SCSChangeCptOutSingle
>>> [   OK ] SerializableFixture.SCSChangeCptOutSingle (0 ms)
>>> [ RUN  ] SerializableFixture.SCSChangeCptOutMultiple
>>> [   OK ] SerializableFixture.SCSChangeCptOutMultiple (1 ms)
>>> [ RUN  ] SerializableFixture.SCSChangeCptOutLarge
>>> [   OK ] SerializableFixture.SCSChangeCptOutLarge (0 ms)
>>> [ RUN  ] SerializableFixture.SectionSerializationSimple
>>> [   OK ] SerializableFixture.SectionSerializationSimple (0 ms)
>>> [ RUN  ] SerializableFixture.ParamOutIn
>>> [   OK ] SerializableFixture.ParamOutIn (0 ms)
>>> [ RUN  ] SerializableFixture.ParamOutInMultipleSections
>>> [   OK ] SerializableFixture.ParamOutInMultipleSections (0 ms)
>>> [--] 6 tests from SerializableFixture (2 ms total)
>>>
>>> [--] Global test environment tear-down
>>> [==] 33 tests from 8 test suites ran. (171 ms total)
>>> [  PASSED  ] 33 tests.
>>>
>>>   YOU HAVE 1 DISABLED TEST
>>>
>>> [   OK ] LoggingDeathTest.PanicLoggerExitHelper (149 ms)
>>> [ RUN  ] LoggingDeathTest.ExitMessage
>>> [   OK ] LoggingDeathTest.ExitMessage (152 ms)
>>> [ RUN  ] LoggingDeathTest.Panic
>>> [   OK ] LoggingDeathTest.Panic (151 ms)
>>> [ RUN  ] LoggingDeathTest.Fatal
>>> [   OK ] LoggingDeathTest.Fatal (2 ms)
>>> [ RUN  ] LoggingDeathTest.PanicIf
>>> [   OK ] LoggingDeathTest.PanicIf (150 ms)
>>> [ RUN  ] LoggingDeathTest.FatalIf
>>> [   OK ] LoggingDeathTest.FatalIf (3 ms)
>>> [ RUN  ] LoggingDeathTest.gem5Assert
>>> [  SKIPPED ] LoggingDeathTest.gem5Assert (0 ms)
>>> [--] 13 tests from LoggingDeathTest (1216 ms total)
>>>
>>> [--] 21 tests from LoggingFixture
>>> [ RUN  ] LoggingFixture.BasicPrint
>>> [   OK ] LoggingFixture.BasicPrint (0 ms)
>>> [ RUN  ] LoggingFixture.VariadicCharPrint
>>> [   OK ] LoggingFixture.VariadicCharPrint (0 ms)
>>> [ RUN  ] LoggingFixture.VariadicStringPrint
>>> [   OK ] LoggingFixture.VariadicStringPrint (0 ms)
>>> [ RUN  ] LoggingFixture.VariadicCharMissingPrint
>>> [   OK ] LoggingFixture.VariadicCharMissingPrint (0 ms)
>>> [ RUN  ] LoggingFixture.VariadicStringMissingPrint
>>> [   OK ] LoggingFixture.VariadicStringMissingPrint (0 ms)
>>> [ RUN  ] LoggingFixture.DisabledPrint
>>> [   OK ] LoggingFixture.DisabledPrint (0 ms)
>>> [ RUN  ] LoggingFixture.WarnLoggerPrint
>>> [   OK ] LoggingFixture.WarnLoggerPrint (0 ms)
>>> [ RUN  ] LoggingFixture.InfoLoggerPrint
>>> [   OK ] LoggingFixture.InfoLoggerPrint (0 ms)
>>> [ RUN  ] LoggingFixture.HackLoggerPrint
>>> [   OK ] LoggingFixture.HackLoggerPrint (0

[gem5-dev] Re: Build failed in Jenkins: nightly #27

2021-11-01 Thread Jason Lowe-Power via gem5-dev 
I don't think so. The binaries haven't been updated since April
('aarch-system-20210904.tar.bz2'). Well, the blame says April even if the
filename is confusing (DDMM?).

Here's the failure:
https://jenkins.gem5.org/job/nightly/ws/tests/testing-results/SuiteUID%3Arealview-o3-ARM-x86_64-opt/TestUID%3Arealview-o3-ARM-x86_64-opt/simerr

build/ARM/arch/arm/insts/pseudo.cc:173: warn: instruction 'csdb'
unimplemented
build/ARM/arch/arm/generated/decoder-ns.cc.inc:100643: warn: instruction
'mcr bpiall' unimplemented
gem5 has encountered a segmentation fault!

Cheers,
Jason

On Sat, Oct 30, 2021 at 4:11 AM Gabe Black via gem5-dev 
wrote:

> Maybe you need to re-download the resources?
>
> Gabe
>
> On Sat, Oct 30, 2021 at 3:50 AM jenkins-no-reply--- via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> See 
>>
>> Changes:
>>
>>
>> --
>> [...truncated 809.58 KB...]
>> [--] 4 tests from CheckpointInFixture
>> [ RUN  ] CheckpointInFixture.FindSections
>> [   OK ] CheckpointInFixture.FindSections (1 ms)
>> [ RUN  ] CheckpointInFixture.FindEntries
>> [   OK ] CheckpointInFixture.FindEntries (0 ms)
>> [ RUN  ] CheckpointInFixture.ExtractEntries
>> [   OK ] CheckpointInFixture.ExtractEntries (0 ms)
>> [ RUN  ] CheckpointInFixture.SCSCptInPathScoped
>> [   OK ] CheckpointInFixture.SCSCptInPathScoped (0 ms)
>> [--] 4 tests from CheckpointInFixture (1 ms total)
>>
>> [--] 6 tests from SerializableFixture
>> [ RUN  ] SerializableFixture.SCSChangeCptOutSingle
>> [   OK ] SerializableFixture.SCSChangeCptOutSingle (0 ms)
>> [ RUN  ] SerializableFixture.SCSChangeCptOutMultiple
>> [   OK ] SerializableFixture.SCSChangeCptOutMultiple (1 ms)
>> [ RUN  ] SerializableFixture.SCSChangeCptOutLarge
>> [   OK ] SerializableFixture.SCSChangeCptOutLarge (0 ms)
>> [ RUN  ] SerializableFixture.SectionSerializationSimple
>> [   OK ] SerializableFixture.SectionSerializationSimple (0 ms)
>> [ RUN  ] SerializableFixture.ParamOutIn
>> [   OK ] SerializableFixture.ParamOutIn (0 ms)
>> [ RUN  ] SerializableFixture.ParamOutInMultipleSections
>> [   OK ] SerializableFixture.ParamOutInMultipleSections (0 ms)
>> [--] 6 tests from SerializableFixture (2 ms total)
>>
>> [--] Global test environment tear-down
>> [==] 33 tests from 8 test suites ran. (171 ms total)
>> [  PASSED  ] 33 tests.
>>
>>   YOU HAVE 1 DISABLED TEST
>>
>> [   OK ] LoggingDeathTest.PanicLoggerExitHelper (149 ms)
>> [ RUN  ] LoggingDeathTest.ExitMessage
>> [   OK ] LoggingDeathTest.ExitMessage (152 ms)
>> [ RUN  ] LoggingDeathTest.Panic
>> [   OK ] LoggingDeathTest.Panic (151 ms)
>> [ RUN  ] LoggingDeathTest.Fatal
>> [   OK ] LoggingDeathTest.Fatal (2 ms)
>> [ RUN  ] LoggingDeathTest.PanicIf
>> [   OK ] LoggingDeathTest.PanicIf (150 ms)
>> [ RUN  ] LoggingDeathTest.FatalIf
>> [   OK ] LoggingDeathTest.FatalIf (3 ms)
>> [ RUN  ] LoggingDeathTest.gem5Assert
>> [  SKIPPED ] LoggingDeathTest.gem5Assert (0 ms)
>> [--] 13 tests from LoggingDeathTest (1216 ms total)
>>
>> [--] 21 tests from LoggingFixture
>> [ RUN  ] LoggingFixture.BasicPrint
>> [   OK ] LoggingFixture.BasicPrint (0 ms)
>> [ RUN  ] LoggingFixture.VariadicCharPrint
>> [   OK ] LoggingFixture.VariadicCharPrint (0 ms)
>> [ RUN  ] LoggingFixture.VariadicStringPrint
>> [   OK ] LoggingFixture.VariadicStringPrint (0 ms)
>> [ RUN  ] LoggingFixture.VariadicCharMissingPrint
>> [   OK ] LoggingFixture.VariadicCharMissingPrint (0 ms)
>> [ RUN  ] LoggingFixture.VariadicStringMissingPrint
>> [   OK ] LoggingFixture.VariadicStringMissingPrint (0 ms)
>> [ RUN  ] LoggingFixture.DisabledPrint
>> [   OK ] LoggingFixture.DisabledPrint (0 ms)
>> [ RUN  ] LoggingFixture.WarnLoggerPrint
>> [   OK ] LoggingFixture.WarnLoggerPrint (0 ms)
>> [ RUN  ] LoggingFixture.InfoLoggerPrint
>> [   OK ] LoggingFixture.InfoLoggerPrint (0 ms)
>> [ RUN  ] LoggingFixture.HackLoggerPrint
>> [   OK ] LoggingFixture.HackLoggerPrint (0 ms)
>> [ RUN  ] LoggingFixture.FatalLoggerPrint
>> [   OK ] LoggingFixture.FatalLoggerPrint (0 ms)
>> [ RUN  ] LoggingFixture.PanicLoggerPrint
>> [   OK ] LoggingFixture.PanicLoggerPrint (0 ms)
>> [ RUN  ] LoggingFixture.BaseMessage
>> [   OK ] LoggingFixture.BaseMessage (0 ms)
>> [ RUN  ] LoggingFixture.BaseMessageOnce
>> [   OK ] LoggingFixture.BaseMessageOnce (0 ms)
>> [ RUN  ] LoggingFixture.Warn
>> [   OK ] LoggingFixture.Warn (0 ms)
>> [ RUN  ] LoggingFixture.Inform
>> [   OK ] LoggingFixture.Inform (0 ms)
>> [ RUN  ] LoggingFixture.Hack
>> [   OK ] LoggingFixture.Hack (0 ms)
>> [ RUN  ] LoggingFixture.WarnOnce
>> [   OK ] LoggingFixture.WarnOnce (0 ms)
>> [ RUN  ] LoggingFixture.InformOnce
>> [   OK ]

[gem5-dev] Re: Build failed in Jenkins: nightly #27

2021-10-30 Thread Gabe Black via gem5-dev 
Maybe you need to re-download the resources?

Gabe

On Sat, Oct 30, 2021 at 3:50 AM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See 
>
> Changes:
>
>
> --
> [...truncated 809.58 KB...]
> [--] 4 tests from CheckpointInFixture
> [ RUN  ] CheckpointInFixture.FindSections
> [   OK ] CheckpointInFixture.FindSections (1 ms)
> [ RUN  ] CheckpointInFixture.FindEntries
> [   OK ] CheckpointInFixture.FindEntries (0 ms)
> [ RUN  ] CheckpointInFixture.ExtractEntries
> [   OK ] CheckpointInFixture.ExtractEntries (0 ms)
> [ RUN  ] CheckpointInFixture.SCSCptInPathScoped
> [   OK ] CheckpointInFixture.SCSCptInPathScoped (0 ms)
> [--] 4 tests from CheckpointInFixture (1 ms total)
>
> [--] 6 tests from SerializableFixture
> [ RUN  ] SerializableFixture.SCSChangeCptOutSingle
> [   OK ] SerializableFixture.SCSChangeCptOutSingle (0 ms)
> [ RUN  ] SerializableFixture.SCSChangeCptOutMultiple
> [   OK ] SerializableFixture.SCSChangeCptOutMultiple (1 ms)
> [ RUN  ] SerializableFixture.SCSChangeCptOutLarge
> [   OK ] SerializableFixture.SCSChangeCptOutLarge (0 ms)
> [ RUN  ] SerializableFixture.SectionSerializationSimple
> [   OK ] SerializableFixture.SectionSerializationSimple (0 ms)
> [ RUN  ] SerializableFixture.ParamOutIn
> [   OK ] SerializableFixture.ParamOutIn (0 ms)
> [ RUN  ] SerializableFixture.ParamOutInMultipleSections
> [   OK ] SerializableFixture.ParamOutInMultipleSections (0 ms)
> [--] 6 tests from SerializableFixture (2 ms total)
>
> [--] Global test environment tear-down
> [==] 33 tests from 8 test suites ran. (171 ms total)
> [  PASSED  ] 33 tests.
>
>   YOU HAVE 1 DISABLED TEST
>
> [   OK ] LoggingDeathTest.PanicLoggerExitHelper (149 ms)
> [ RUN  ] LoggingDeathTest.ExitMessage
> [   OK ] LoggingDeathTest.ExitMessage (152 ms)
> [ RUN  ] LoggingDeathTest.Panic
> [   OK ] LoggingDeathTest.Panic (151 ms)
> [ RUN  ] LoggingDeathTest.Fatal
> [   OK ] LoggingDeathTest.Fatal (2 ms)
> [ RUN  ] LoggingDeathTest.PanicIf
> [   OK ] LoggingDeathTest.PanicIf (150 ms)
> [ RUN  ] LoggingDeathTest.FatalIf
> [   OK ] LoggingDeathTest.FatalIf (3 ms)
> [ RUN  ] LoggingDeathTest.gem5Assert
> [  SKIPPED ] LoggingDeathTest.gem5Assert (0 ms)
> [--] 13 tests from LoggingDeathTest (1216 ms total)
>
> [--] 21 tests from LoggingFixture
> [ RUN  ] LoggingFixture.BasicPrint
> [   OK ] LoggingFixture.BasicPrint (0 ms)
> [ RUN  ] LoggingFixture.VariadicCharPrint
> [   OK ] LoggingFixture.VariadicCharPrint (0 ms)
> [ RUN  ] LoggingFixture.VariadicStringPrint
> [   OK ] LoggingFixture.VariadicStringPrint (0 ms)
> [ RUN  ] LoggingFixture.VariadicCharMissingPrint
> [   OK ] LoggingFixture.VariadicCharMissingPrint (0 ms)
> [ RUN  ] LoggingFixture.VariadicStringMissingPrint
> [   OK ] LoggingFixture.VariadicStringMissingPrint (0 ms)
> [ RUN  ] LoggingFixture.DisabledPrint
> [   OK ] LoggingFixture.DisabledPrint (0 ms)
> [ RUN  ] LoggingFixture.WarnLoggerPrint
> [   OK ] LoggingFixture.WarnLoggerPrint (0 ms)
> [ RUN  ] LoggingFixture.InfoLoggerPrint
> [   OK ] LoggingFixture.InfoLoggerPrint (0 ms)
> [ RUN  ] LoggingFixture.HackLoggerPrint
> [   OK ] LoggingFixture.HackLoggerPrint (0 ms)
> [ RUN  ] LoggingFixture.FatalLoggerPrint
> [   OK ] LoggingFixture.FatalLoggerPrint (0 ms)
> [ RUN  ] LoggingFixture.PanicLoggerPrint
> [   OK ] LoggingFixture.PanicLoggerPrint (0 ms)
> [ RUN  ] LoggingFixture.BaseMessage
> [   OK ] LoggingFixture.BaseMessage (0 ms)
> [ RUN  ] LoggingFixture.BaseMessageOnce
> [   OK ] LoggingFixture.BaseMessageOnce (0 ms)
> [ RUN  ] LoggingFixture.Warn
> [   OK ] LoggingFixture.Warn (0 ms)
> [ RUN  ] LoggingFixture.Inform
> [   OK ] LoggingFixture.Inform (0 ms)
> [ RUN  ] LoggingFixture.Hack
> [   OK ] LoggingFixture.Hack (0 ms)
> [ RUN  ] LoggingFixture.WarnOnce
> [   OK ] LoggingFixture.WarnOnce (0 ms)
> [ RUN  ] LoggingFixture.InformOnce
> [   OK ] LoggingFixture.InformOnce (0 ms)
> [ RUN  ] LoggingFixture.HackOnce
> [   OK ] LoggingFixture.HackOnce (0 ms)
> [ RUN  ] LoggingFixture.WarnIf
> [   OK ] LoggingFixture.WarnIf (0 ms)
> [ RUN  ] LoggingFixture.WarnIfOnce
> [   OK ] LoggingFixture.WarnIfOnce (0 ms)
> [--] 21 tests from LoggingFixture (0 ms total)
>
> [--] Global test environment tear-down
> [==] 34 tests from 2 test suites ran. (1216 ms total)
> [  PASSED  ] 32 tests.
> [  SKIPPED ] 2 tests, listed below:
> [  SKIPPED ] LoggingDeathTest.EmptyPrefix
> [  SKIPPED ] LoggingDeathTest.gem5Assert
> scons: done building targets.
> *** Summary of Warnings ***
> Warning: Deprecated namespaces are not supported by this compiler.
>

[gem5-dev] Re: Build failed in Jenkins: Nightly #27

2020-08-07 Thread Gabe Black via gem5-dev 
Sorry for the breakage, thanks for the fix!

Gabe

On Fri, Aug 7, 2020 at 8:03 AM Jason Lowe-Power via gem5-dev <
gem5-dev@gem5.org> wrote:

> Feel free to post a fix if you have one!
>
> Cheers,
> Jason
>
> On Fri, Aug 7, 2020 at 7:58 AM Poremba, Matthew 
> wrote:
>
>> [AMD Public Use]
>>
>>
>>
>> The line that has the error should be deleted to fix the MIPS build.  I
>> missed that in the review.  I can post a fix if you want but I thought I’d
>> give Gabe a chance to take a look.
>>
>>
>>
>>
>>
>> -Matt
>>
>>
>>
>> *From:* Jason Lowe-Power via gem5-dev 
>> *Sent:* Thursday, August 6, 2020 7:36 AM
>> *To:* gem5 Developer List ; Bobby Bruce <
>> bbr...@ucdavis.edu>
>> *Cc:* Jason Lowe-Power 
>> *Subject:* [gem5-dev] Re: Build failed in Jenkins: Nightly #27
>>
>>
>>
>> [CAUTION: External Email]
>>
>> Cool! The nightly builds are "working"! (At least in the sense that they
>> let us know when something failed :D)
>>
>>
>>
>> It looks like the change that caused this issue is
>> https://gem5-review.googlesource.com/c/public/gem5/+/29403
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgem5-review.googlesource.com%2Fc%2Fpublic%2Fgem5%2F%2B%2F29403=02%7C01%7Cmatthew.poremba%40amd.com%7C321f165569a34ae5ac2f08d83a163afb%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637323214451683905=t2pzfK9BE3ov5Xt48iAcrZsTghpnMmwHcF7dY1itPgU%3D=0>
>> .
>>
>>
>>
>> @Bobby Bruce , it might be nice if this message
>> could give us links to the commits. If we can't get links to the gerrit
>> easily, at least links to gem5.googlesource.com
>> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgem5.googlesource.com%2F=02%7C01%7Cmatthew.poremba%40amd.com%7C321f165569a34ae5ac2f08d83a163afb%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637323214451683905=3eFJM%2B%2FIs6b%2BXhUhw1s1EMVK04DPMjHs0ZHksEuvuY8%3D=0>
>> would be useful.
>>
>>
>>
>> Cheers,
>>
>> Jason
>>
>>
>>
>> On Thu, Aug 6, 2020 at 1:51 AM jenkins-no-reply--- via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>> See <
>> https://jenkins.gem5.org/job/Nightly/27/display/redirect?page=changes
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjenkins.gem5.org%2Fjob%2FNightly%2F27%2Fdisplay%2Fredirect%3Fpage%3Dchanges=02%7C01%7Cmatthew.poremba%40amd.com%7C321f165569a34ae5ac2f08d83a163afb%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637323214451693903=lC8%2FcrUiPWMD2A81%2BG3MA2vZ%2BuHAu4eNOc%2BJKnDQ%2FO4%3D=0>
>> >
>>
>> Changes:
>>
>> [gabeblack] scons: Remove the plumbing for running regression tests from
>> scons.
>>
>> [gabeblack] tests: Get rid of the tests/tests.py script.
>>
>> [gabeblack] tests: Get rid of the tests/testing python package.
>>
>> [gabeblack] tests: Get rid of the now unused diff-out script.
>>
>> [gabeblack] util: Delete the util/regress script.
>>
>> [Bobby R. Bruce] utils,tests: Enable passing of build args to
>> compiler-tests.sh
>>
>> [gabeblack] scons: Remove explicitly set defaults in calls to AddOption.
>>
>> [gabeblack] scons: Delete the now unused --update-ref option.
>>
>> [gabeblack] sim: Convert stat functions to use VPtr.
>>
>> [gabeblack] arch: Use VPtr for uname.
>>
>> [gabeblack] scons: Make src/systemc/tests/SConscript python 3 compatible.
>>
>> [gabeblack] scons,fastmodel: Limit how many instances of simgen can run
>> at once.
>>
>> [gabeblack] systemc: Filter a pydot warning message out when checking
>> test output.
>>
>> [gabeblack] systemc: Adjust some type names in a couple tests.
>>
>> [gabeblack] cpu: Remove the "profile" parameter and plumbing.
>>
>>
>> --
>> [...truncated 40.75 KB...]
>>  [VER TAGS]  -> MIPS/sim/tags.cc
>>  [ CXX] MIPS/sim/debug.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/MachineType.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/L1Cache_Wakeup.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/Directory_Transitions.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/Directory_Wakeup.cc -> .o
>>  [LINK]  -> MIPS/cpu/simple/probes/lib.o.partial
>>  [ CXX] MIPS/mem/ruby/protocol/DMA_Controller.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/DMA_Transitions.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/DMA_Wakeup.cc -> .o
>>  [ CXX] MIPS/mem/

[gem5-dev] Re: Build failed in Jenkins: Nightly #27

2020-08-07 Thread Jason Lowe-Power via gem5-dev 
Feel free to post a fix if you have one!

Cheers,
Jason

On Fri, Aug 7, 2020 at 7:58 AM Poremba, Matthew 
wrote:

> [AMD Public Use]
>
>
>
> The line that has the error should be deleted to fix the MIPS build.  I
> missed that in the review.  I can post a fix if you want but I thought I’d
> give Gabe a chance to take a look.
>
>
>
>
>
> -Matt
>
>
>
> *From:* Jason Lowe-Power via gem5-dev 
> *Sent:* Thursday, August 6, 2020 7:36 AM
> *To:* gem5 Developer List ; Bobby Bruce <
> bbr...@ucdavis.edu>
> *Cc:* Jason Lowe-Power 
> *Subject:* [gem5-dev] Re: Build failed in Jenkins: Nightly #27
>
>
>
> [CAUTION: External Email]
>
> Cool! The nightly builds are "working"! (At least in the sense that they
> let us know when something failed :D)
>
>
>
> It looks like the change that caused this issue is
> https://gem5-review.googlesource.com/c/public/gem5/+/29403
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgem5-review.googlesource.com%2Fc%2Fpublic%2Fgem5%2F%2B%2F29403=02%7C01%7Cmatthew.poremba%40amd.com%7C321f165569a34ae5ac2f08d83a163afb%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637323214451683905=t2pzfK9BE3ov5Xt48iAcrZsTghpnMmwHcF7dY1itPgU%3D=0>
> .
>
>
>
> @Bobby Bruce , it might be nice if this message could
> give us links to the commits. If we can't get links to the gerrit easily,
> at least links to gem5.googlesource.com
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgem5.googlesource.com%2F=02%7C01%7Cmatthew.poremba%40amd.com%7C321f165569a34ae5ac2f08d83a163afb%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637323214451683905=3eFJM%2B%2FIs6b%2BXhUhw1s1EMVK04DPMjHs0ZHksEuvuY8%3D=0>
> would be useful.
>
>
>
> Cheers,
>
> Jason
>
>
>
> On Thu, Aug 6, 2020 at 1:51 AM jenkins-no-reply--- via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
> See <https://jenkins.gem5.org/job/Nightly/27/display/redirect?page=changes
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjenkins.gem5.org%2Fjob%2FNightly%2F27%2Fdisplay%2Fredirect%3Fpage%3Dchanges=02%7C01%7Cmatthew.poremba%40amd.com%7C321f165569a34ae5ac2f08d83a163afb%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637323214451693903=lC8%2FcrUiPWMD2A81%2BG3MA2vZ%2BuHAu4eNOc%2BJKnDQ%2FO4%3D=0>
> >
>
> Changes:
>
> [gabeblack] scons: Remove the plumbing for running regression tests from
> scons.
>
> [gabeblack] tests: Get rid of the tests/tests.py script.
>
> [gabeblack] tests: Get rid of the tests/testing python package.
>
> [gabeblack] tests: Get rid of the now unused diff-out script.
>
> [gabeblack] util: Delete the util/regress script.
>
> [Bobby R. Bruce] utils,tests: Enable passing of build args to
> compiler-tests.sh
>
> [gabeblack] scons: Remove explicitly set defaults in calls to AddOption.
>
> [gabeblack] scons: Delete the now unused --update-ref option.
>
> [gabeblack] sim: Convert stat functions to use VPtr.
>
> [gabeblack] arch: Use VPtr for uname.
>
> [gabeblack] scons: Make src/systemc/tests/SConscript python 3 compatible.
>
> [gabeblack] scons,fastmodel: Limit how many instances of simgen can run at
> once.
>
> [gabeblack] systemc: Filter a pydot warning message out when checking test
> output.
>
> [gabeblack] systemc: Adjust some type names in a couple tests.
>
> [gabeblack] cpu: Remove the "profile" parameter and plumbing.
>
>
> --
> [...truncated 40.75 KB...]
>  [VER TAGS]  -> MIPS/sim/tags.cc
>  [ CXX] MIPS/sim/debug.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/MachineType.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/L1Cache_Wakeup.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/Directory_Transitions.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/Directory_Wakeup.cc -> .o
>  [LINK]  -> MIPS/cpu/simple/probes/lib.o.partial
>  [ CXX] MIPS/mem/ruby/protocol/DMA_Controller.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/DMA_Transitions.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/DMA_Wakeup.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/L1Cache_Controller.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/L1Cache_Transitions.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/Directory_Controller.cc -> .o
>  [ CXX] MIPS/sim/kernel_workload.cc -> .o
>  [ CXX] MIPS/sim/stat_control.cc -> .o
>  [ CXX] MIPS/sim/system.cc -> .o
>  [ CXX] MIPS/sim/faults.cc -> .o
>  [LINK]  -> MIPS/mem/ruby/protocol/lib.o.partial
>  [ CXX] MIPS/sim/process.cc -> .o
>  [ CXX] MIPS/sim/mem_state.cc -> .o
>  [SO PARAM] BaseCPU -> MIPS/params/BaseCPU.hh
>  [ CXX] MIPS/sim/pseudo_ins

[gem5-dev] Re: Build failed in Jenkins: Nightly #27

2020-08-07 Thread Poremba, Matthew via gem5-dev 
[AMD Public Use]

The line that has the error should be deleted to fix the MIPS build.  I missed 
that in the review.  I can post a fix if you want but I thought I'd give Gabe a 
chance to take a look.


-Matt

From: Jason Lowe-Power via gem5-dev 
Sent: Thursday, August 6, 2020 7:36 AM
To: gem5 Developer List ; Bobby Bruce 
Cc: Jason Lowe-Power 
Subject: [gem5-dev] Re: Build failed in Jenkins: Nightly #27

[CAUTION: External Email]
Cool! The nightly builds are "working"! (At least in the sense that they let us 
know when something failed :D)

It looks like the change that caused this issue is 
https://gem5-review.googlesource.com/c/public/gem5/+/29403<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgem5-review.googlesource.com%2Fc%2Fpublic%2Fgem5%2F%2B%2F29403=02%7C01%7Cmatthew.poremba%40amd.com%7C321f165569a34ae5ac2f08d83a163afb%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637323214451683905=t2pzfK9BE3ov5Xt48iAcrZsTghpnMmwHcF7dY1itPgU%3D=0>.

@Bobby Bruce<mailto:bbr...@ucdavis.edu>, it might be nice if this message could 
give us links to the commits. If we can't get links to the gerrit easily, at 
least links to 
gem5.googlesource.com<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgem5.googlesource.com%2F=02%7C01%7Cmatthew.poremba%40amd.com%7C321f165569a34ae5ac2f08d83a163afb%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637323214451683905=3eFJM%2B%2FIs6b%2BXhUhw1s1EMVK04DPMjHs0ZHksEuvuY8%3D=0>
 would be useful.

Cheers,
Jason

On Thu, Aug 6, 2020 at 1:51 AM jenkins-no-reply--- via gem5-dev 
mailto:gem5-dev@gem5.org>> wrote:
See 
<https://jenkins.gem5.org/job/Nightly/27/display/redirect?page=changes<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjenkins.gem5.org%2Fjob%2FNightly%2F27%2Fdisplay%2Fredirect%3Fpage%3Dchanges=02%7C01%7Cmatthew.poremba%40amd.com%7C321f165569a34ae5ac2f08d83a163afb%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637323214451693903=lC8%2FcrUiPWMD2A81%2BG3MA2vZ%2BuHAu4eNOc%2BJKnDQ%2FO4%3D=0>>

Changes:

[gabeblack] scons: Remove the plumbing for running regression tests from scons.

[gabeblack] tests: Get rid of the tests/tests.py script.

[gabeblack] tests: Get rid of the tests/testing python package.

[gabeblack] tests: Get rid of the now unused diff-out script.

[gabeblack] util: Delete the util/regress script.

[Bobby R. Bruce] utils,tests: Enable passing of build args to compiler-tests.sh

[gabeblack] scons: Remove explicitly set defaults in calls to AddOption.

[gabeblack] scons: Delete the now unused --update-ref option.

[gabeblack] sim: Convert stat functions to use VPtr.

[gabeblack] arch: Use VPtr for uname.

[gabeblack] scons: Make src/systemc/tests/SConscript python 3 compatible.

[gabeblack] scons,fastmodel: Limit how many instances of simgen can run at once.

[gabeblack] systemc: Filter a pydot warning message out when checking test 
output.

[gabeblack] systemc: Adjust some type names in a couple tests.

[gabeblack] cpu: Remove the "profile" parameter and plumbing.


--
[...truncated 40.75 KB...]
 [VER TAGS]  -> MIPS/sim/tags.cc
 [ CXX] MIPS/sim/debug.cc -> .o
 [ CXX] MIPS/mem/ruby/protocol/MachineType.cc -> .o
 [ CXX] MIPS/mem/ruby/protocol/L1Cache_Wakeup.cc -> .o
 [ CXX] MIPS/mem/ruby/protocol/Directory_Transitions.cc -> .o
 [ CXX] MIPS/mem/ruby/protocol/Directory_Wakeup.cc -> .o
 [LINK]  -> MIPS/cpu/simple/probes/lib.o.partial
 [ CXX] MIPS/mem/ruby/protocol/DMA_Controller.cc -> .o
 [ CXX] MIPS/mem/ruby/protocol/DMA_Transitions.cc -> .o
 [ CXX] MIPS/mem/ruby/protocol/DMA_Wakeup.cc -> .o
 [ CXX] MIPS/mem/ruby/protocol/L1Cache_Controller.cc -> .o
 [ CXX] MIPS/mem/ruby/protocol/L1Cache_Transitions.cc -> .o
 [ CXX] MIPS/mem/ruby/protocol/Directory_Controller.cc -> .o
 [ CXX] MIPS/sim/kernel_workload.cc -> .o
 [ CXX] MIPS/sim/stat_control.cc -> .o
 [ CXX] MIPS/sim/system.cc -> .o
 [ CXX] MIPS/sim/faults.cc -> .o
 [LINK]  -> MIPS/mem/ruby/protocol/lib.o.partial
 [ CXX] MIPS/sim/process.cc -> .o
 [ CXX] MIPS/sim/mem_state.cc -> .o
 [SO PARAM] BaseCPU -> MIPS/params/BaseCPU.hh
 [ CXX] MIPS/sim/pseudo_inst.cc -> .o
 [ CXX] MIPS/sim/syscall_emul.cc -> .o
 [ CXX] MIPS/sim/syscall_desc.cc -> .o
 [ CXX] MIPS/cpu/testers/directedtest/DirectedGenerator.cc -> .o
 [ CXX] MIPS/cpu/o3/probe/simple_trace.cc -> .o
 [ CXX] MIPS/cpu/o3/probe/elastic_trace.cc -> .o
 [ CXX] MIPS/cpu/testers/traffic_gen/base.cc -> .o
 [LINK]  -> MIPS/sim/lib.o.partial
 [ CXX] MIPS/cpu/testers/traffic_gen/base_gen.cc -> .o
 [ CXX] MIPS/cpu/testers/traffic_gen/traffic_gen.cc -> .o
 [ CXX] MIPS/python/_m5/param_AtomicSimpleCPU.cc -> .o
 [SO PyBind] BaseCPU -> MIPS/python/_m5/param_BaseCPU.cc
 [ CXX] MIPS/python/_m5/param_BaseCPU.cc -> .o

[gem5-dev] Re: Build failed in Jenkins: Nightly #27

2020-08-06 Thread Jason Lowe-Power via gem5-dev 
Cool! The nightly builds are "working"! (At least in the sense that they
let us know when something failed :D)

It looks like the change that caused this issue is
https://gem5-review.googlesource.com/c/public/gem5/+/29403.

@Bobby Bruce , it might be nice if this message could
give us links to the commits. If we can't get links to the gerrit easily,
at least links to gem5.googlesource.com would be useful.

Cheers,
Jason

On Thu, Aug 6, 2020 at 1:51 AM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See  >
>
> Changes:
>
> [gabeblack] scons: Remove the plumbing for running regression tests from
> scons.
>
> [gabeblack] tests: Get rid of the tests/tests.py script.
>
> [gabeblack] tests: Get rid of the tests/testing python package.
>
> [gabeblack] tests: Get rid of the now unused diff-out script.
>
> [gabeblack] util: Delete the util/regress script.
>
> [Bobby R. Bruce] utils,tests: Enable passing of build args to
> compiler-tests.sh
>
> [gabeblack] scons: Remove explicitly set defaults in calls to AddOption.
>
> [gabeblack] scons: Delete the now unused --update-ref option.
>
> [gabeblack] sim: Convert stat functions to use VPtr.
>
> [gabeblack] arch: Use VPtr for uname.
>
> [gabeblack] scons: Make src/systemc/tests/SConscript python 3 compatible.
>
> [gabeblack] scons,fastmodel: Limit how many instances of simgen can run at
> once.
>
> [gabeblack] systemc: Filter a pydot warning message out when checking test
> output.
>
> [gabeblack] systemc: Adjust some type names in a couple tests.
>
> [gabeblack] cpu: Remove the "profile" parameter and plumbing.
>
>
> --
> [...truncated 40.75 KB...]
>  [VER TAGS]  -> MIPS/sim/tags.cc
>  [ CXX] MIPS/sim/debug.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/MachineType.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/L1Cache_Wakeup.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/Directory_Transitions.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/Directory_Wakeup.cc -> .o
>  [LINK]  -> MIPS/cpu/simple/probes/lib.o.partial
>  [ CXX] MIPS/mem/ruby/protocol/DMA_Controller.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/DMA_Transitions.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/DMA_Wakeup.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/L1Cache_Controller.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/L1Cache_Transitions.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/Directory_Controller.cc -> .o
>  [ CXX] MIPS/sim/kernel_workload.cc -> .o
>  [ CXX] MIPS/sim/stat_control.cc -> .o
>  [ CXX] MIPS/sim/system.cc -> .o
>  [ CXX] MIPS/sim/faults.cc -> .o
>  [LINK]  -> MIPS/mem/ruby/protocol/lib.o.partial
>  [ CXX] MIPS/sim/process.cc -> .o
>  [ CXX] MIPS/sim/mem_state.cc -> .o
>  [SO PARAM] BaseCPU -> MIPS/params/BaseCPU.hh
>  [ CXX] MIPS/sim/pseudo_inst.cc -> .o
>  [ CXX] MIPS/sim/syscall_emul.cc -> .o
>  [ CXX] MIPS/sim/syscall_desc.cc -> .o
>  [ CXX] MIPS/cpu/testers/directedtest/DirectedGenerator.cc -> .o
>  [ CXX] MIPS/cpu/o3/probe/simple_trace.cc -> .o
>  [ CXX] MIPS/cpu/o3/probe/elastic_trace.cc -> .o
>  [ CXX] MIPS/cpu/testers/traffic_gen/base.cc -> .o
>  [LINK]  -> MIPS/sim/lib.o.partial
>  [ CXX] MIPS/cpu/testers/traffic_gen/base_gen.cc -> .o
>  [ CXX] MIPS/cpu/testers/traffic_gen/traffic_gen.cc -> .o
>  [ CXX] MIPS/python/_m5/param_AtomicSimpleCPU.cc -> .o
>  [SO PyBind] BaseCPU -> MIPS/python/_m5/param_BaseCPU.cc
>  [ CXX] MIPS/python/_m5/param_BaseCPU.cc -> .o
>  [LINK]  -> MIPS/cpu/o3/probe/lib.o.partial
>  [ CXX] MIPS/python/_m5/param_BaseCache.cc -> .o
>  [LINK]  -> MIPS/cpu/testers/traffic_gen/lib.o.partial
>  [ CXX] MIPS/python/_m5/param_BasePrefetcher.cc -> .o
>  [ CXX] MIPS/python/_m5/param_BaseSetAssoc.cc -> .o
>  [ CXX] MIPS/python/_m5/param_BaseSimpleCPU.cc -> .o
>  [ CXX] MIPS/python/_m5/param_BaseTags.cc -> .o
>  [ CXX] MIPS/python/_m5/param_BaseTrafficGen.cc -> .o
>  [ CXX] MIPS/python/_m5/param_BiModeBP.cc -> .o
>  [ CXX] MIPS/python/_m5/param_BranchPredictor.cc -> .o
>  [ CXX] MIPS/python/_m5/param_Cache.cc -> .o
>  [ CXX] MIPS/python/_m5/param_CheckerCPU.cc -> .o
>  [ CXX] MIPS/python/_m5/param_CoherentXBar.cc -> .o
>  [ CXX] MIPS/python/_m5/param_CommMonitor.cc -> .o
>  [ CXX] MIPS/python/_m5/param_CopyEngine.cc -> .o
>  [ CXX] MIPS/python/_m5/param_DMA_Controller.cc -> .o
>  [ CXX] MIPS/python/_m5/param_DRAMCtrl.cc -> .o
>  [ CXX] MIPS/python/_m5/param_DerivO3CPU.cc -> .o
>  [ CXX] MIPS/python/_m5/param_DirectedGenerator.cc -> .o
>  [ CXX] MIPS/python/_m5/param_Directory_Controller.cc -> .o
>  [ CXX] MIPS/python/_m5/param_DmaDevice.cc -> .o
>  [ CXX] MIPS/python/_m5/param_DummyChecker.cc -> .o
>  [ CXX] MIPS/python/_m5/param_ElasticTrace.cc -> .o
>  [ CXX] MIPS/python/_m5/param_EtherDevBase.cc -> .o
>  [ CXX] MIPS/python/_m5/param_EtherDevice.cc -> .o
>