Native rts not working on linux (glibc)

Native rts not working on linux (glibc)

[Anders Gidenstam]

Hello!

When I compile programs that uses the native rts instead of the fsu rts,
they fail when I try to run them.

[d96andgi@aragorn Test]$ ./greet2 
Failed Runtime Assertion : GNULLI failure---Set_Priority

I think it's some problem with the LinuxThread library but I'm not sure.
I use the gnat-3.10p-1 rpm package and I have glibc version 2.0.7-19.
(The system is more or less RedHat 5.1 and ... well.. it's a PC)

Has someone managed to use the native rts with a similar setup?

Btw is there any way to link the program with the rts dynamically?
(My binaries are even bigger than those on Solaris/Sparc...)

/Anders 
-- 
--------------------------------------------
"A well-written program is its own heaven; 
 a poorly-written program is its own hell."
  - The Tao of Programming 

Re: Native rts not working on linux (glibc)

[Sune Falck]

Try to run the program when logged in as root.

I got the same problem a while ago when trying
out gnat on Linux Red Hat 5.1. I suspect there
is some kind of privilege problem - the gnat run
time is maybe trying to change the queuing policy
for threads.

/Sune Falck

Anders Gidenstam skrev i meddelandet <717sfl$ple$1@nyheter.chalmers.se>...
>Hello!
>
>When I compile programs that uses the native rts instead of the fsu rts,
>they fail when I try to run them.
>
>[d96andgi@aragorn Test]$ ./greet2
>Failed Runtime Assertion : GNULLI failure---Set_Priority
>

Re: Native rts not working on linux (glibc)

[Anders Gidenstam]

In article <71a813$p9v$1@news.han.telia.se>,
	"Sune Falck" <Sune.S.Falck@telia.se> writes:
>Try to run the program when logged in as root.
>
>I got the same problem a while ago when trying
>out gnat on Linux Red Hat 5.1. I suspect there
>is some kind of privilege problem - the gnat run
>time is maybe trying to change the queuing policy
>for threads.

>>[d96andgi@aragorn Test]$ ./greet2
>>Failed Runtime Assertion : GNULLI failure---Set_Priority

That did the job!! Thanks!!!

But there must be a way to avoid this..?
And how do I do to link with the rts dynamically, 
so the binaries get smaller?

/Anders
-- 
--------------------------------------------
"A well-written program is its own heaven; 
 a poorly-written program is its own hell."
  - The Tao of Programming 

Re: Native rts not working on linux (glibc)

[Anders Gidenstam]

In article <71ac9n$npj$1@nyheter.chalmers.se>,
	d96andgi@dtek.chalmers.se (Anders Gidenstam) writes:
>In article <71a813$p9v$1@news.han.telia.se>,
>	"Sune Falck" <Sune.S.Falck@telia.se> writes:
>>Try to run the program when logged in as root.
>>
>>I got the same problem a while ago when trying
>>out gnat on Linux Red Hat 5.1. I suspect there
>>is some kind of privilege problem - the gnat run
>>time is maybe trying to change the queuing policy
>>for threads.
>
>>>[d96andgi@aragorn Test]$ ./greet2
>>>Failed Runtime Assertion : GNULLI failure---Set_Priority
>
>That did the job!! Thanks!!!
>
>But there must be a way to avoid this..?
I would prefer to be able to run the programs without root privileges.
(The multithreaded mandelbrot example that comes with adabindx
 nuked my system... :( )
Is there any possible way to do that?
Also, single task programs that use adabindx dumps core when compiled
with rts-native (they did work with rts-fsu).

/Anders
-- 
--------------------------------------------
"A well-written program is its own heaven; 
 a poorly-written program is its own hell."
  - The Tao of Programming 

Re: Native rts not working on linux (glibc)

[drees]

In article <717sfl$ple$1@nyheter.chalmers.se>,
  d96andgi@dtek.chalmers.se (Anders Gidenstam) wrote:
> Hello!

Hi!

> When I compile programs that uses the native rts instead of the fsu rts,
> they fail when I try to run them.
>
> [d96andgi@aragorn Test]$ ./greet2
> Failed Runtime Assertion : GNULLI failure---Set_Priority

I get the same thing with the native package.

> I think it's some problem with the LinuxThread library but I'm not sure.
> I use the gnat-3.10p-1 rpm package and I have glibc version 2.0.7-19.
> (The system is more or less RedHat 5.1 and ... well.. it's a PC)
>
> Has someone managed to use the native rts with a similar setup?

I haven't gotten it to work using the rts-native, but I got my programs to
run with rts-fsu, apparently just fine.  Here's how to do it.  You need to
patch the s-osinte.ads file and rebuild the files just like you did to the
rts-native files.  Apply this patch.  (I installed gnat in /opt/gnat)
**************************** ---
/opt/gnat/lib/gcc-lib/i386-linux/2.7.2.1/rts-fsu/adainclude/s-osinte.ads.orig
Wed Nov 11 22:25:57 1998 +++
/opt/gnat/lib/gcc-lib/i386-linux/2.7.2.1/rts-fsu/adainclude/s-osinte.ads Wed
Nov 11 22:36:11 1998 @@ -648,7 +648,9 @@

 private

-   type sigset_t is new unsigned_long;
+   SIGSET_NWORDS : constant := 1024 / (unsigned_long'Size);
+
+   type sigset_t is array (1 .. SIGSET_NWORDS) of unsigned_long;

    --  In Solaris 2.4 the component sa_handler turns out to
    --  be one a union type, and the selector is a macro:
*******************************

Then rebuild all the libs in rts-fsu/adalib with the following script:

********************************
#!/bin/tcsh -f
foreach f (../adainclude/*.ad[bs])
  gcc -c -O2 -gnatpga -I- $f
end
********************************

And remember to point your adainclude and adalib to rts-fsu/adainclude and
lib.

> Btw is there any way to link the program with the rts dynamically?
> (My binaries are even bigger than those on Solaris/Sparc...

Sorry, no help here.

-Dave

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Native rts not working on linux (glibc)

[Anders Gidenstam]

In article <72e20a$8h5$1@nnrp1.dejanews.com>,
	drees@oto.dyn.ml.org writes:
> In article <717sfl$ple$1@nyheter.chalmers.se>,
>   d96andgi@dtek.chalmers.se (Anders Gidenstam) wrote:
>> Hello!
> 
> Hi!
> 
>> When I compile programs that uses the native rts instead of the fsu rts,
>> they fail when I try to run them.
>>
>> [d96andgi@aragorn Test]$ ./greet2
>> Failed Runtime Assertion : GNULLI failure---Set_Priority
> 
> I get the same thing with the native package.

I've received a reply explaining that problem...
You have to run your program as root since the rts tries to change
the scheduling-policy (or something similar...).

That is clearly not very good, I've managed to cause a complete 
system lockup when I trying some threaded Motif programs...

/Anders

-- 
--------------------------------------------
"A well-written program is its own heaven; 
 a poorly-written program is its own hell."
  - The Tao of Programming 

Re: Native rts not working on linux (glibc)

[dewarr]

In article <72egna$6na$1@nyheter.chalmers.se>,
  d96andgi@dtek.chalmers.se (Anders Gidenstam) wrote:
> In article <72e20a$8h5$1@nnrp1.dejanews.com>,
> 	drees@oto.dyn.ml.org writes:
> > In article <717sfl$ple$1@nyheter.chalmers.se>,
> >   d96andgi@dtek.chalmers.se (Anders Gidenstam) wrote:
> >> Hello!
> >
> > Hi!
> >
> >> When I compile programs that uses the native rts
instead of the fsu rts,
> >> they fail when I try to run them.
> >>
> >> [d96andgi@aragorn Test]$ ./greet2
> >> Failed Runtime Assertion : GNULLI
failure---Set_Priority
> >
> > I get the same thing with the native package.
>
> I've received a reply explaining that problem...
> You have to run your program as root since the rts tries
to change
> the scheduling-policy (or something similar...).
>
> That is clearly not very good, I've managed to cause a
complete
> system lockup when I trying some threaded Motif
programs...
>


Ada 95 Annex D semantics require run-till-blocked with
absolute priority control. The only way to achieve this
in Linux is with real time threads under root mode, and
yes, of course you can lock up your system this way!

It sounds in any case as though the system is mis-built if
you are getting these assertion errors.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Native rts not working on linux (glibc)

[Anders Gidenstam]

In article <72evc1$l0$1@nnrp1.dejanews.com>,
	dewarr@my-dejanews.com writes:
> Ada 95 Annex D semantics require run-till-blocked with
> absolute priority control. The only way to achieve this
> in Linux is with real time threads under root mode, and
> yes, of course you can lock up your system this way!
> 
> It sounds in any case as though the system is mis-built if
> you are getting these assertion errors.

What part of the system? glibc, the compiler or the rts?

So there isn't anyway to build programs that can be run without root access?
(On linux, that is... the programs works fine on Solaris)
(The fsu-rts is rather useless when one task (and therefor the rts) is 
(almost) always blocked in the 'application main loop' of motif)

/Anders
-- 
--------------------------------------------
"A well-written program is its own heaven; 
 a poorly-written program is its own hell."
  - The Tao of Programming 

Re: Native rts not working on linux (glibc)

[Simon Wright]

d96andgi@dtek.chalmers.se (Anders Gidenstam) writes:

> In article <72evc1$l0$1@nnrp1.dejanews.com>,
> 	dewarr@my-dejanews.com writes:
> > Ada 95 Annex D semantics require run-till-blocked with
> > absolute priority control. The only way to achieve this
> > in Linux is with real time threads under root mode, and
> > yes, of course you can lock up your system this way!
> > 
> > It sounds in any case as though the system is mis-built if
> > you are getting these assertion errors.
> 
> What part of the system? glibc, the compiler or the rts?
> 
> So there isn't anyway to build programs that can be run without root access?
> (On linux, that is... the programs works fine on Solaris)
> (The fsu-rts is rather useless when one task (and therefor the rts) is 
> (almost) always blocked in the 'application main loop' of motif)

Tasking programs will run fine on Linux with GNAT. If they don't there
is something wrong!

As far as I can tell the code that does this is in Set_Priority in s-taprop.adb:

      Result := pthread_setschedparam (T.LL.Thread, SCHED_FIFO, Param'Access);
      pragma Assert (Result = 0 or else Result = EPERM);

If you are root, you get the priority (Result = 0)
If not, the request fails quietly     (Result = EPERM)
.. or something terrible has occurred

The behaviour here is just like that on Solaris (well, at any rate on
the 2.6 we are using).


One thing to be wary of, what glibc are you using? I ask because I
have glibc1 (libc.so.5.4.44) & libpthread 0.71, and that gives
horrible problems with X and Ada tasking; I think it does something to
select(). I put some notes on this at
http://www.pogner.demon.co.uk/gnat-x-threads/ . If you do take this
up, be warned that you will have trouble building X-based programs
(specifically, Emacs!)

-Simon

Re: Native rts not working on linux (glibc)

[Anders Gidenstam]

In article <x7vaf1sr9ty.fsf@pogner.demon.co.uk>,
	Simon Wright <simon@pogner.demon.co.uk> writes:
>Tasking programs will run fine on Linux with GNAT. If they don't there
>is something wrong!
>
>As far as I can tell the code that does this is in Set_Priority in s-taprop.adb:
>
>      Result := pthread_setschedparam (T.LL.Thread, SCHED_FIFO, Param'Access);
>      pragma Assert (Result = 0 or else Result = EPERM);
>
>If you are root, you get the priority (Result = 0)
>If not, the request fails quietly     (Result = EPERM)
>... or something terrible has occurred

Well, I've found the problem my s-taprop.adb looks like tihs:

  Result := pthread_setschedparam (T.LL.Thread, SCHED_FIFO, Param'Access);
  pragma Assert (Result = 0
                 or else Shutdown ("GNULLI failure---Set_Priority"));

Not very strange that my programs didn't run...(when I wasn't root)...
Might it be possible to remove the offending Shutdown and just ignore
that the call failed? 

/Anders
-- 
--------------------------------------------
"A well-written program is its own heaven; 
 a poorly-written program is its own hell."
  - The Tao of Programming 

Re: Native rts not working on linux (glibc)

[Simon Wright]

d96andgi@dtek.chalmers.se (Anders Gidenstam) writes:

> In article <x7vaf1sr9ty.fsf@pogner.demon.co.uk>,
> 	Simon Wright <simon@pogner.demon.co.uk> writes:
> >Tasking programs will run fine on Linux with GNAT. If they don't there
> >is something wrong!
> >
> >As far as I can tell the code that does this is in Set_Priority in s-taprop.adb:
> >
> >      Result := pthread_setschedparam (T.LL.Thread, SCHED_FIFO, Param'Access);
> >      pragma Assert (Result = 0 or else Result = EPERM);
> >
> >If you are root, you get the priority (Result = 0)
> >If not, the request fails quietly     (Result = EPERM)
> >... or something terrible has occurred
> 
> Well, I've found the problem my s-taprop.adb looks like tihs:
> 
>   Result := pthread_setschedparam (T.LL.Thread, SCHED_FIFO, Param'Access);
>   pragma Assert (Result = 0
>                  or else Shutdown ("GNULLI failure---Set_Priority"));
> 
> Not very strange that my programs didn't run...(when I wasn't root)...
> Might it be possible to remove the offending Shutdown and just ignore
> that the call failed? 

Oh dear, I think the code I posted was from a not-yet-released GNAT
version. Now you show me the code you see, I seem to remember finding
the same code last time I looked and being puzzled that tasking was
working!

If you are getting the GNULLI message indicated then it certainly
would seem worth trying this change.

Re: Native rts not working on linux (glibc)

[Anders Gidenstam]

In article <x7vaf1q3j4q.fsf@pogner.demon.co.uk>,
	Simon Wright <simon@pogner.demon.co.uk> writes:
> Oh dear, I think the code I posted was from a not-yet-released GNAT
> version. Now you show me the code you see, I seem to remember finding
> the same code last time I looked and being puzzled that tasking was
> working!
> 
> If you are getting the GNULLI message indicated then it certainly
> would seem worth trying this change.

I changed the code and now things work! Thanks!
(I had to recompile the Motif bindings, though)

/Anders
-- 
--------------------------------------------
"A well-written program is its own heaven; 
 a poorly-written program is its own hell."
  - The Tao of Programming 

Re: Native rts not working on linux (glibc)

[Anders Gidenstam]

In article <x7vaf1sr9ty.fsf@pogner.demon.co.uk>,
	Simon Wright <simon@pogner.demon.co.uk> writes:
>Tasking programs will run fine on Linux with GNAT. If they don't there
>is something wrong!
>
>One thing to be wary of, what glibc are you using? I ask because I
>have glibc1 (libc.so.5.4.44) & libpthread 0.71, and that gives
>horrible problems with X and Ada tasking; I think it does something to
>select(). I put some notes on this at
>http://www.pogner.demon.co.uk/gnat-x-threads/ . If you do take this
>up, be warned that you will have trouble building X-based programs
>(specifically, Emacs!)

I use glibc 2.0.7-19 and the gnat rpm. (It's a Redhat 5.1 system)
And for the X stuff I use the adabindx bindings and they work for
programs compiled with the fsu rts (but other tasks than the one controlling the GUI
does only run when the GUI is 'activated' and if I have another task that can block
on some external call too (ex listening on a socket) things go horribly wrong...)
Programs compiled with the native rts works when run as root.
(X-based programs does not work though, but since I've compiled the X bindings with the 
fsu rts this might be the source of some of the problems.)  

/Anders
-- 
--------------------------------------------
"A well-written program is its own heaven; 
 a poorly-written program is its own hell."
  - The Tao of Programming