Can run mono once and only once (EEE PC)?

[simozzer]

Hello,

I wonder if anyone can help me with fixing this?

After lots of package upgrades I've finally managed to get mono 2.0 installed on my EEE PC -Yey!

It seems, however, I can run any mono application once then I have to reboot - Boo!

After reboot the first mono application i try to run runs fine - the next freezes :(

I've tried debugging using gdb but i've never gdb debugged anything in my life so I haven't got very far. Here follows the gdb output from two successive runs of HelloWorld.exe:

Starting program: /opt/mono/2.0/bin/mono /home/user/HelloWorld.exe
[Thread debugging using libthread_db enabled]
[New Thread -1210984736 (LWP 8969)]
[New Thread -1218667600 (LWP 8970)]
[New Thread -1218815056 (LWP 8971)]
Hello

Program received signal SIGPWR, Power fail/restart.
[Switching to Thread -1218815056 (LWP 8971)]
0xb7e7dc01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0
(gdb) continue
Continuing.

Program received signal SIGXCPU, CPU time limit exceeded.
0xb7d47e3d in sigsuspend () from /lib/tls/libc.so.6
(gdb) c
Continuing.

Program exited normally.
(gdb) run /home/user/HelloWorld.exe
Starting program: /opt/mono/2.0/bin/mono /home/user/HelloWorld.exe
[Thread debugging using libthread_db enabled]
[New Thread -1210964256 (LWP 8972)]
[New Thread -1218647120 (LWP 8973)]

At this point gdb freezes - what keys can i press to halt execution and  inspect the call stack to find out what the heck is happening?

Can anyone help? P.lease, it would be wonderful to get Mono and MonoDevelop up and running on a 4GB handheld 'toy' :o)

Cheers

Mozzy


 

[simozzer]

Can anyone please help me here?

I can run mono 1.2.6 absolutely fine with no problems but with 2.0 I always experience a lock-up. The lockup occurs both when I have built mono from trunk and also when i try installing the (unsupported) binary distribution.

Any hints to help me debug this would be much appreciated.

Cheers

Mozzy

simozzer wrote:

Hello,

I wonder if anyone can help me with fixing this?

After lots of package upgrades I've finally managed to get mono 2.0 installed on my EEE PC -Yey!

It seems, however, I can run any mono application once then I have to reboot - Boo!

After reboot the first mono application i try to run runs fine - the next freezes :(

I've tried debugging using gdb but i've never gdb debugged anything in my life so I haven't got very far. Here follows the gdb output from two successive runs of HelloWorld.exe:

Starting program: /opt/mono/2.0/bin/mono /home/user/HelloWorld.exe
[Thread debugging using libthread_db enabled]
[New Thread -1210984736 (LWP 8969)]
[New Thread -1218667600 (LWP 8970)]
[New Thread -1218815056 (LWP 8971)]
Hello

Program received signal SIGPWR, Power fail/restart.
[Switching to Thread -1218815056 (LWP 8971)]
0xb7e7dc01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0
(gdb) continue
Continuing.

Program received signal SIGXCPU, CPU time limit exceeded.
0xb7d47e3d in sigsuspend () from /lib/tls/libc.so.6
(gdb) c
Continuing.

Program exited normally.
(gdb) run /home/user/HelloWorld.exe
Starting program: /opt/mono/2.0/bin/mono /home/user/HelloWorld.exe
[Thread debugging using libthread_db enabled]
[New Thread -1210964256 (LWP 8972)]
[New Thread -1218647120 (LWP 8973)]

At this point gdb freezes - what keys can i press to halt execution and  inspect the call stack to find out what the heck is happening?

Can anyone help? P.lease, it would be wonderful to get Mono and MonoDevelop up and running on a 4GB handheld 'toy' :o)

Cheers

Mozzy


 

[simozzer]

I've narrowed it down to a call in threads.c, line 766:

pthread_getattr_np(pthread_self(), &attr).

I'm still no wiser though. Does anyone have any insight as to why this call might be causing some kind of deadlock?

Thanks

Simozzer.



Can anyone please help me here?

I can run mono 1.2.6 absolutely fine with no problems but with 2.0 I always experience a lock-up. The lockup occurs both when I have built mono from trunk and also when i try installing the (unsupported) binary distribution.

Any hints to help me debug this would be much appreciated.

Cheers

Mozzy

simozzer wrote:

Hello,

I wonder if anyone can help me with fixing this?

After lots of package upgrades I've finally managed to get mono 2.0 installed on my EEE PC -Yey!

It seems, however, I can run any mono application once then I have to reboot - Boo!

After reboot the first mono application i try to run runs fine - the next freezes :(

I've tried debugging using gdb but i've never gdb debugged anything in my life so I haven't got very far. Here follows the gdb output from two successive runs of HelloWorld.exe:

Starting program: /opt/mono/2.0/bin/mono /home/user/HelloWorld.exe
[Thread debugging using libthread_db enabled]
[New Thread -1210984736 (LWP 8969)]
[New Thread -1218667600 (LWP 8970)]
[New Thread -1218815056 (LWP 8971)]
Hello

Program received signal SIGPWR, Power fail/restart.
[Switching to Thread -1218815056 (LWP 8971)]
0xb7e7dc01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0
(gdb) continue
Continuing.

Program received signal SIGXCPU, CPU time limit exceeded.
0xb7d47e3d in sigsuspend () from /lib/tls/libc.so.6
(gdb) c
Continuing.

Program exited normally.
(gdb) run /home/user/HelloWorld.exe
Starting program: /opt/mono/2.0/bin/mono /home/user/HelloWorld.exe
[Thread debugging using libthread_db enabled]
[New Thread -1210964256 (LWP 8972)]
[New Thread -1218647120 (LWP 8973)]

At this point gdb freezes - what keys can i press to halt execution and  inspect the call stack to find out what the heck is happening?

Can anyone help? P.lease, it would be wonderful to get Mono and MonoDevelop up and running on a 4GB handheld 'toy' :o)

Cheers

Mozzy


 

[Dallman, John-2]

> I've narrowed it down to a call in threads.c, line 766:
>
> pthread_getattr_np(pthread_self(), &attr).
>
> I'm still no wiser though. Does anyone have any insight as to why this
> call might be causing some kind of deadlock?

Look very carefully at what happens with that attribute resource
structure.
Is it getting re-used for the second call that causes the deadlock? How
is
it allocated?

--
John Dallman
Parasolid Porting Engineer

Siemens PLM Software
46 Regent Street, Cambridge, CB2 1DP
United Kingdom
Tel: [phone]
john.dallman@...
www.siemens.com/plm

> -----Original Message-----
> From: mono-list-bounces@... [mailto:mono-list-
> bounces@...] On Behalf Of simozzer
> Sent: Sunday, August 17, 2008 11:14 PM
> To: mono-list@...
> Subject: Re: [Mono-list] Can run mono once and only once ( Mono locks
> up when calling pthread_getattr_np ).
>
>
> I've narrowed it down to a call in threads.c, line 766:
>
> pthread_getattr_np(pthread_self(), &attr).
>
> I'm still no wiser though. Does anyone have any insight as to why this
> call
> might be causing some kind of deadlock?
>
> Thanks
>
> Simozzer.
>
>
>
> simozzer wrote:
> >
> > Can anyone please help me here?
> >
> > I can run mono 1.2.6 absolutely fine with no problems but with 2.0 I
> > always experience a lock-up. The lockup occurs both when I have

built

> mono
> > from trunk and also when i try installing the (unsupported) binary
> > distribution.
> >
> > Any hints to help me debug this would be much appreciated.
> >
> > Cheers
> >
> > Mozzy
> >
> >
> > simozzer wrote:
> >>
> >> Hello,
> >>
> >> I wonder if anyone can help me with fixing this?
> >>
> >> After lots of package upgrades I've finally managed to get mono 2.0
> >> installed on my EEE PC -Yey!
> >>
> >> It seems, however, I can run any mono application once then I have
> to
> >> reboot - Boo!
> >>
> >> After reboot the first mono application i try to run runs fine -

the
> next
> >> freezes :(
> >>
> >> I've tried debugging using gdb but i've never gdb debugged anything
> in my
> >> life so I haven't got very far. Here follows the gdb output from
two

> >> successive runs of HelloWorld.exe:
> >>
> >> Starting program: /opt/mono/2.0/bin/mono /home/user/HelloWorld.exe
> >> [Thread debugging using libthread_db enabled]
> >> [New Thread -1210984736 (LWP 8969)]
> >> [New Thread -1218667600 (LWP 8970)]
> >> [New Thread -1218815056 (LWP 8971)]
> >> Hello
> >>
> >> Program received signal SIGPWR, Power fail/restart.
> >> [Switching to Thread -1218815056 (LWP 8971)]
> >> 0xb7e7dc01 in pthread_cond_wait@@GLIBC_2.3.2 () from
> >> /lib/tls/libpthread.so.0
> >> (gdb) continue
> >> Continuing.
> >>
> >> Program received signal SIGXCPU, CPU time limit exceeded.
> >> 0xb7d47e3d in sigsuspend () from /lib/tls/libc.so.6
> >> (gdb) c
> >> Continuing.
> >>
> >> Program exited normally.
> >> (gdb) run /home/user/HelloWorld.exe
> >> Starting program: /opt/mono/2.0/bin/mono /home/user/HelloWorld.exe
> >> [Thread debugging using libthread_db enabled]
> >> [New Thread -1210964256 (LWP 8972)]
> >> [New Thread -1218647120 (LWP 8973)]
> >>
> >> At this point gdb freezes - what keys can i press to halt execution
> and
> >> inspect the call stack to find out what the heck is happening?
> >>
> >> Can anyone help? P.lease, it would be wonderful to get Mono and
> >> MonoDevelop up and running on a 4GB handheld 'toy' :o)
> >>
> >> Cheers
> >>
> >> Mozzy
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Can-run-mono-once-
> and-only-once-%28EEE-PC%29--tp18821807p19023849.html
> Sent from the Mono - General mailing list archive at Nabble.com.
>
> _______________________________________________
> Mono-list maillist  -  Mono-list@...
> http://lists.ximian.com/mailman/listinfo/mono-list

_______________________________________________
Mono-list maillist  -  Mono-list@...
http://lists.ximian.com/mailman/listinfo/mono-list

[simozzer]

John,

Thanks for your reply. I'm afraid my lack of c, gdb and linux debugging knowledge is letting me down here.

It appears that the attribute structure is allocated in the few lines just before the lock occurs. At first glance it does not appear that the program is trying to reuse the same structure on second run (it should be a new instance?).

( code snippet from mono_thread_get_stack_bounds)
pthread_attr_t attr;
guint8 *current = (guint8*)&attr;
pthread_attr_init(&attr);
pthread_getattr_np(pthread_self(),&attr);

I'm going to try rebooting and stepping through the first (succesfull) run to see if I can trace what is happening with the attr structure on the first run - unless you have any other suggestions?





> I've narrowed it down to a call in threads.c, line 766:
>
> pthread_getattr_np(pthread_self(), &attr).
>
> I'm still no wiser though. Does anyone have any insight as to why this
> call might be causing some kind of deadlock?

Look very carefully at what happens with that attribute resource
structure.
Is it getting re-used for the second call that causes the deadlock? How
is
it allocated?

--
John Dallman
Parasolid Porting Engineer

Siemens PLM Software
46 Regent Street, Cambridge, CB2 1DP
United Kingdom
Tel: [phone]
[e-mail]
www.siemens.com/plm

[simozzer]

Wow this is becoming freaky.

Further to the lockup which I previously reported I've just discovered this strange behaviour: If I run my mono HelloWorld.exe through gdb and leave it paused at the first breakpoint (gdb receives a  - I can then run mono HelloWorld.exe as many times as i like outside the debugger. As soon as I let the version being debugged run till completion I can no longer run mono HelloWorld.exe without it locking up.

There's something strange going on in the termination code but I cannot work out what. I'd like to report a bug but i would like it to be reproducable - has anyone else experienced these wierd little lockups?

Cheers

Mozzy




John,

Thanks for your reply. I'm afraid my lack of c, gdb and linux debugging knowledge is letting me down here.

It appears that the attribute structure is allocated in the few lines just before the lock occurs. At first glance it does not appear that the program is trying to reuse the same structure on second run (it should be a new instance?).

( code snippet from mono_thread_get_stack_bounds)
pthread_attr_t attr;
guint8 *current = (guint8*)&attr;
pthread_attr_init(&attr);
pthread_getattr_np(pthread_self(),&attr);

I'm going to try rebooting and stepping through the first (succesfull) run to see if I can trace what is happening with the attr structure on the first run - unless you have any other suggestions?

Dallman, John-2 wrote:

> I've narrowed it down to a call in threads.c, line 766:
>
> pthread_getattr_np(pthread_self(), &attr).
>
> I'm still no wiser though. Does anyone have any insight as to why this
> call might be causing some kind of deadlock?

Look very carefully at what happens with that attribute resource
structure.
Is it getting re-used for the second call that causes the deadlock? How
is
it allocated?

--
John Dallman
Parasolid Porting Engineer

Siemens PLM Software
46 Regent Street, Cambridge, CB2 1DP
United Kingdom
Tel: [phone]
[e-mail]
www.siemens.com/plm

[Robert Jordan]

Hi,

simozzer wrote:

> Wow this is becoming freaky.
>
> Further to the lockup which I previously reported I've just discovered this
> strange behaviour: If I run my mono HelloWorld.exe through gdb and leave it
> paused at the first breakpoint (gdb receives a  - I can then run mono
> HelloWorld.exe as many times as i like outside the debugger. As soon as I
> let the version being debugged run till completion I can no longer run mono
> HelloWorld.exe without it locking up.
>
> There's something strange going on in the termination code but I cannot work
> out what. I'd like to report a bug but i would like it to be reproducable -
> has anyone else experienced these wierd little lockups?

Try `MONO_DISABLE_SHM=1 mono HelloWorld.exe'

Robert

_______________________________________________
Mono-list maillist  -  Mono-list@...
http://lists.ximian.com/mailman/listinfo/mono-list

[Andreas Färber]

Am 19.08.2008 um 15:38 schrieb simozzer:

> If I run my mono HelloWorld.exe through gdb and leave it
> paused at the first breakpoint (gdb receives a  - I can then run mono
> HelloWorld.exe as many times as i like outside the debugger. As soon  
> as I
> let the version being debugged run till completion I can no longer  
> run mono
> HelloWorld.exe without it locking up.

Have you tried compiling with shared handles disabled?

Andreas

_______________________________________________
Mono-list maillist  -  Mono-list@...
http://lists.ximian.com/mailman/listinfo/mono-list

[simozzer]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Robert,

>> Try `MONO_DISABLE_SHM=1 mono HelloWorld.exe'

Thanks, that worked excellently!

I've had another email from Andreas Färber asking me to try with shared handles disabled - is that what this command (MONO_DISABLE_SHM=1) does? 


Thanks again,

Mozzy.

---

Get fish-slapping on Messenger! Play Now
_______________________________________________
Mono-list maillist  -  Mono-list@...
http://lists.ximian.com/mailman/listinfo/mono-list

[Andreas Färber]

Am 19.08.2008 um 16:06 schrieb SIMON MOSCROP:

>> Try `MONO_DISABLE_SHM=1 mono HelloWorld.exe'

Thanks, that worked excellently! 

I've had another email from Andreas Färber asking me to try with shared handles disabled - is that what this command (MONO_DISABLE_SHM=1) does?

I guess so. --disable-shared-handles does not compile them in, MONO_DISABLE_SHM would seem to disable it at runtime.

Andreas

_______________________________________________
Mono-list maillist  -  Mono-list@...
http://lists.ximian.com/mailman/listinfo/mono-list