This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug ada/35284] Branch to 0x0 from Ada run-time



------- Comment #7 from joel dot sherrill at oarcorp dot com  2008-02-21 23:55 -------
Subject: Re:  Branch to 0x0 from Ada run-time

laurent at guerby dot net wrote:
> ------- Comment #6 from laurent at guerby dot net  2008-02-21 22:59 -------
> Could you post the exact backtrace on my testcase? 

Breakpoint 1, 0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0x00106079 in system.tasking.stages.task_wrapper (self_id=0x1de234)
    at s-tassta.adb:1140
#2  0x0012c72f in _Thread_Handler ()
    at 
../../../../../../../423/rtems/c/src/../../cpukit/score/src/threadhandler.c:151
#3  0x00000071 in ?? ()
#4  0x0000037f in ?? ()
#5  0x00000000 in ?? ()

I don't know if this helps but

(gdb) p/x _Thread_Executing->Object.id
$1 = 0xb010003

Which indicates this is the third POSIX thread created in
this test.

(1) RTEMS POSIX_Init
(2) main Ada task
(3) your task A

> It purposely doesn't use the
> complex Text_IO so things should be clearer. Also if you could use gdb to get
> an understanding of what is done during adainit execution before the failure
> point.
>   
I also disabled clock tick interrupts since this test doesn't
appear to have any need for time to be passing.

I didn't attach a log yet because I don't think this is in
initialization.  I think adainit is doing
the right thing.  I think this is a finalization problem.  When
I break at system__standard_library__adafinal (aka (Do_Finalize),
T has been  printed but not the A.  When the main thread blocks
in "Timed_Sleep" from something near here:

system.tasking.stages.finalize_global_tasks () at s-tassta.adb:796

I traced it through the context switch that happens via Timed_Sleep
and I was surprised to see that your Task T has NEVER run.  When
we context switch to your Task T, we go directly to the RTEMS
_Thread_Handler wrapper for all thread entries which calls the
Ada thread wrapper entry.  So while we are finalizing, it is
getting context switched to for the first time.  That seems
like a solid lead.

I will trace further into what is happening in the morning. 
At this point, it seems like finalizing a thread that hasn't
started yet is tripping something funny.

If someone gets a good idea before I start again in the
morning, just post it.

> PS: continuing after sleep for me :)
>
>   
I am on my way to register my youngest
son for high school for the fall.  Wow!

You should be sleeping.  It is late in Paris.

Thanks.

--joel
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
>
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>   


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]