Ciro,
When I merged the changes in from that patch and its relations I started
getting a crash instead of a hang. That crash, I can reproduce on develop.
gem5.opt: build/X86/cpu/o3/cpu.cc:823: void
FullO3CPU<Impl>::removeThread(ThreadID)
[with Impl = O3CPUImpl; ThreadID = short int]: Assertion
`commit.rob->isEmpty(tid)' failed.
Check out the gem5-users thread from last week:
[gem5-users] gem5 pthread regression with O3CPU on x86?
Incidentally this highlights the need for a slack or something like that
for gem5-users/develop where we can tag people etc.
Anyway:
I am working on a fix and will open a ticket. Apparently it works ok
on ARM, Derrick Greenspan ran it.. Not sure what that means, it might just
happen to be that the ROB is empty when the ARM core is halted, I think
that the flaw is in the cpu code itself. (See my description in that
thread).
Dan
On Mon, Nov 2, 2020 at 7:19 AM Ciro Santilli <ciro.santi...@arm.com> wrote:
> Daniel, if you manage to reproduce on clean develop, please also open an
> issue at https://gem5.atlassian.net/jira/software/c/projects/GEM5/issues I'd
> also be curious to see if it reproduces on se.py (so I could see if it also
> happens on ARM).
>
> We've had some ARM-specific SE issues e.g. at
> https://gem5.atlassian.net/browse/GEM5-537 but this is X86 so I'm not
> sure. With SyscallAll + ExecAll and some patience most bugs can be found.
> Presumably new instructions are being run in an infinite loop, otherwise
> simulation would reach the end of time. So I would try to determine what
> that minimal loop is and why it won't exit.
> ------------------------------
> *From:* Daniel Gerzhoy via gem5-users <gem5-users@gem5.org>
> *Sent:* Wednesday, October 28, 2020 7:21 PM
> *To:* gem5 users mailing list <gem5-users@gem5.org>
> *Cc:* Daniel Gerzhoy <daniel.gerz...@gmail.com>
> *Subject:* [gem5-users] Re: SE Mode and Std::thread
>
> Looks like this is related to this change:
>
> https://gem5-review.googlesource.com/c/public/gem5/+/8184
>
> I'm a bit behind develop because of custom changes and don't have this
> patch merged yet.
> Cherry picking this might work, but merging would probably be the best
> solution, if time consuming.
>
> Cheers,
> Dan
>
>
> On Tue, Oct 27, 2020 at 3:39 PM Daniel Gerzhoy <daniel.gerz...@gmail.com>
> wrote:
>
> Hey all,
>
> I'm running into a strange issue where threads are not spawning when
> launched with std::thread. It seems to work once, and then I try to launch
> again using a newly allocated thread pointer (after deleting the old one)
> and it hangs.
>
> Minimal example:
>
> void foo()
> {
> printf("Foo alive from tid %lu\n", m5_cpu_id());
> //m5_cpu_id is a pseudo_instruction I added to return tc->cpuId()
> }
>
> void main()
> {
> printf("Launching foo 1"\n);
> std::thread * mythread = new std::thread(foo,...);
> printf("Done Launching foo 1"\n);
>
> printf("Joining foo 1"\n);
> myThread->join();
> delete myThread;
>
> printf("Launching foo 2"\n);
> mythread = new std::thread(foo,...);
> printf("Done Launching foo 2"\n);
>
> printf("Joining foo 2"\n);
> myThread->join(); //<<<<< IT HANGS HERE
> printf("Done Everything!\n");
> delete myThread;
> }
>
> ______
>
> It works fine with TimingSimpleCPU, but then with DerivO3CPU I get the
> failure.
>
> Output for DerivO3CPU:
> Launch 1
> Done Launch 1
> I'm alive on tid 1
> Launch 2
> Done Launch 2
>
> And there it Hangs.
>
> FYI I am using apu_se.py, though with the above minimal example I've
> managed to reproduce the bug with no GPU code (nor even hipcc) involved.
>
> I went back to the original code I found that showed std::thread could be
> used here:
> https://www.gem5.org/documentation/learning_gem5/part3/running/
>
> [image: image.png]
>
> The comment there that -1 is required for SE mode, and then the subsequent
> comment about appeasing SE mode...
>
> What exactly do those comments mean?
>
> I'm going to keep debugging, but if anyone has any suggestions for debug
> flags that could be helpful it would be appreciated. (I'm using SyscallAll
> and going to investigate some of the syscalls SE mode ignores).
>
> I'm wondering if maybe it is calling join() multiple times that might be
> the problem? Though unsure why at this point.
>
> Thanks!
>
> Dan
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
_______________________________________________
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
