alarm() bug? possibly w/ security update

alarm() seem to be broken on machines that I have upgraded using the
June 2000 product suit CD. (4.25D w/ security patch) I upgraded by
invoking /cd/bin/phinstall - not by using the boot floppy.

After I upgraded my FTP server machine my port of proftpd died with
a timeout message… After fixing the passwd/shadow access and much
fiddling around I discovered that alarm() was not returning the
remaining time - it was returning garbage! But only on the machine I
just upgraded… I have included results from two machines here - one
works as expecetd - the other is the living embodiment of FUBAR…

I also have a machine in the field with the same problem – what’s the
deal – is alarm() broken - Did I screw up the install somehow - is
there an “old” library lurking about - is the newer Proc causing this?

?!?!?!?!?!?

I have isolated the problem in the program included below:
you can compile the program using cc – gcc also shows the same
problem

Also note that the “remaining time” on the broken version is not the
same on each run but will stabliize after the first call i.e 131323,
or 259789016 or… well you get the idea…

Let me know – I’ve got a dead site at the moment…
– Bill

---- test program…

#include <stdio.h>
#include <unistd.h>

// should return a bunck of zeros with the exception of (maybe) the /
// first call
int main( void )
{
unsigned int timeleft;

timeleft = alarm( 0 );
printf( “Initial Time : %d\n”, timeleft );

timeleft = alarm( 0 );
printf( “Initial Time : %d\n”, timeleft );

timeleft = alarm( 0 );
printf( “Initial Time : %d\n”, timeleft );

timeleft = alarm( 0 );
printf( “Initial Time : %d\n”, timeleft );

timeleft = alarm( 0 );
printf( “Initial Time : %d\n”, timeleft );

timeleft = alarm( 0 );
printf( “Initial Time : %d\n”, timeleft );

return (0);
}


– results of run on “working system”

Initial Time : 0
Initial Time : 0
Initial Time : 0
Initial Time : 0
Initial Time : 0
Initial Time : 0

– working system sin ver

PROGRAM NAME VERSION DATE
sys/Proc32 Proc 4.25I Nov 25 1998
sys/Proc32 Slib16 4.23G Oct 04 1996
sys/Slib32 Slib32 4.24B Aug 12 1997
/bin/Fsys Fsys32 4.24T Feb 26 1999
/bin/Fsys Floppy 4.24B Aug 19 1997
/bin/Fsys.eide eide 4.24N Nov 18 1998
//2/bin/Dev32 Dev32 4.23G Oct 04 1996
//2/bin/Dev32.ansi Dev32.ansi 4.23H Nov 21 1996
//2/bin/Dev32.ser Dev32.ser 4.23I Jun 27 1997
//2/bin/Dev32.par Dev.par 4.26 Feb 24 2000
//2/bin/Net Net 4.25C Aug 30 1999
//2/bin/Net.tulip Net.tulip 4.25Q Aug 30 1999
//2/bin/Iso9660fsys Iso9660fsys 4.23D Mar 20 2000
//2/bin/Dosfsys Dosfsys 4.23E Jan 21 1997
//2/bin/Pipe Pipe 4.23A Feb 26 1996
//2/usr/bin/lpsrvr lpsrvr 4.24A Jun 26 1997
//2/bin/Dev32.pty Dev32.pty 4.23G Oct 04 1996
//2//photon/bin/Photon Photon 1.14B Sep 03 1999
//2/
/bin/phfontpfr Photon Font 1.14H Jun 05 2000

------ Upgraded machine program results… Yikes!!!

Initial Time : 6
Initial Time : -1476394993
Initial Time : -1476394993
Initial Time : -1476394993
Initial Time : -1476394993
Initial Time : -1476394993

------ sin ver results…
PROGRAM NAME VERSION DATE
sys/Proc32 Proc 4.25J Sep 09 1999
sys/Proc32 Slib16 4.23G Oct 04 1996
sys/Slib32 Slib32 4.24B Aug 12 1997
/bin/Fsys Fsys32 4.24V Feb 18 2000
/bin/Fsys Floppy 4.24B Aug 19 1997
/bin/Fsys.eide eide 4.25A Feb 09 2000
//1/bin/Dev32 Dev32 4.23G Oct 04 1996
//1/bin/Dev32.ansi Dev32.ansi 4.23H Nov 21 1996
//1/bin/Dev32.ser Dev32.ser 4.23I Jun 27 1997
//1/bin/Dev32.par Dev.par 4.26 Feb 24 2000
//1/bin/Net Net 4.25C Aug 30 1999
//1/bin/Net.ether1000 Net.ether100 4.24B Jul 24 1998
//1/bin/Iso9660fsys Iso9660fsys 4.23D Mar 20 2000
//1/bin/Dosfsys Dosfsys 4.23E Jan 21 1997
//1/bin/Pipe Pipe 4.23A Feb 26 1996
//1/bin/Dev32.pty Dev32.pty 4.23G Oct 04 1996
//1/*/usr/ucb/Socket Socket 4.25H Jul 30 1999

William M. Derby Jr. <derbyw@derbtronics.com> wrote:

I’ve reproduced this in-house.

Same program, same version of Slib32 in both cases – in one case
it runs on Proc 4.25H (and is fine), in the other case, it runs on
Proc 4.25J and is broken.

Actually, on 4.25J the output is consistently:

Initial Time : 6
Initial Time : -1476394993
Initial Time : -1476394993
Initial Time : -1476394993
Initial Time : -1476394993
Initial Time : -1476394993

On 4.25K, the output varies.

I’ve also tested this with timer_settime(), it gets similar behaviour.

(Randy, if you want to look at these, they are sitting in
/home/dagibbs/alarm.c and /home/dagibbs/alarm2.c)

It looks like Proc isn’t filling in the reply structure properly
for type _PROC_TIMER.

-David

QNX Training Services
dagibbs@qnx.com

David Gibbs <dagibbs@qnx.com> wrote:

William M. Derby Jr. <> derbyw@derbtronics.com> > wrote:

It looks like Proc isn’t filling in the reply structure properly
for type _PROC_TIMER.

We’ve found where this is happening wrong, should be fixed internally
in a day or so, and should make the next Proc release. For now, I’d
suggest backdating your Proc32 to one that works. (Or, not updating
it.)

-David

QNX Training Services
dagibbs@qnx.com

On 8 Feb 2001 19:59:23 GMT, David Gibbs <dagibbs@qnx.com> wrote:

David Gibbs <> dagibbs@qnx.com> > wrote:
William M. Derby Jr. <> derbyw@derbtronics.com> > wrote:

It looks like Proc isn’t filling in the reply structure properly
for type _PROC_TIMER.

We’ve found where this is happening wrong, should be fixed internally
in a day or so, and should make the next Proc release. For now, I’d
suggest backdating your Proc32 to one that works. (Or, not updating
it.)
Too late — > :slight_smile:

To “backdate” do I copy a older Proc32 over the one in /boot/sys and
then remake the boot image?? Are there any problems I will have with
other tools wanting to see an up-to-date Proc32?

Hmmm - how often are Proc releases…
I just joined the QNX4 beta (again) - could I get a fixed copy via
that route?

Anyway,
Thanks for looking into this…
Bill

-David

QNX Training Services
dagibbs@qnx.com

William M. Derby Jr. <derbyw@derbtronics.com> wrote:

On 8 Feb 2001 19:59:23 GMT, David Gibbs <> dagibbs@qnx.com> > wrote:

David Gibbs <> dagibbs@qnx.com> > wrote:
William M. Derby Jr. <> derbyw@derbtronics.com> > wrote:

It looks like Proc isn’t filling in the reply structure properly
for type _PROC_TIMER.

We’ve found where this is happening wrong, should be fixed internally
in a day or so, and should make the next Proc release. For now, I’d
suggest backdating your Proc32 to one that works. (Or, not updating
it.)
Too late — > :slight_smile:

To “backdate” do I copy a older Proc32 over the one in /boot/sys and
then remake the boot image?? Are there any problems I will have with
other tools wanting to see an up-to-date Proc32?

I would suggest, actually, copying an older Proc32 to something like
/boot/sys/Proc32.425H (or appropriate version number), change your
build file to include /boot/sys/Proc32.425H (or just sys/Proc32.425H
will work), build the new image, copy /.boot to /.altboot, and then
copy the new image to /.boot.

Most tools don’t check for a specific version of Proc – and, except
over some particular watershed places, the Procs are fairly interchangeable.
Do you want to make sure that your Slib32 (& Slib16 if you are running one)
match your Proc32 – it may not even have been updated, but if it was, you
should back-date it as well.

Hmmm - how often are Proc releases…

Don’t know on this – but the person looking at the code did mutter something
about getting close to another Proc release – at least in beta.

I just joined the QNX4 beta (again) - could I get a fixed copy via
that route?

You should be able to – but I am nowhere near an expert on those
processes.

-David

QNX Training Services
dagibbs@qnx.com

Dave,
Other than the return value, does alarm() function correctly.
Likewise, is it just the return value from timer_settime() that is
incorrect?
Thanks,
ms…

David Gibbs <dagibbs@qnx.com> wrote in message
news:95ur9t$pqm$1@nntp.qnx.com

William M. Derby Jr. <> derbyw@derbtronics.com> > wrote:

I’ve reproduced this in-house.

Same program, same version of Slib32 in both cases – in one case
it runs on Proc 4.25H (and is fine), in the other case, it runs on
Proc 4.25J and is broken.

Actually, on 4.25J the output is consistently:

Initial Time : 6
Initial Time : -1476394993
Initial Time : -1476394993
Initial Time : -1476394993
Initial Time : -1476394993
Initial Time : -1476394993

On 4.25K, the output varies.

I’ve also tested this with timer_settime(), it gets similar behaviour.

(Randy, if you want to look at these, they are sitting in
/home/dagibbs/alarm.c and /home/dagibbs/alarm2.c)

It looks like Proc isn’t filling in the reply structure properly
for type _PROC_TIMER.

-David

QNX Training Services
dagibbs@qnx.com

Mike Schneider <Mike.Schneider@us.heidelberg.com> wrote:

Dave,
Other than the return value, does alarm() function correctly.
Likewise, is it just the return value from timer_settime() that is
incorrect?

Both from testing, and from looking at the code in Proc – yes, it
is just the return values that are incorrect.

The timers will still function properly, and if you do a “sin rt” you
will see the appropriate values for the timers.

-David

QNX Training Services
dagibbs@qnx.com

David Gibbs <dagibbs@qnx.com> wrote:

Mike Schneider <> Mike.Schneider@us.heidelberg.com> > wrote:
Dave,
Other than the return value, does alarm() function correctly.
Likewise, is it just the return value from timer_settime() that is
incorrect?

Both from testing, and from looking at the code in Proc – yes, it
is just the return values that are incorrect.

The timers will still function properly, and if you do a “sin rt” you
will see the appropriate values for the timers.

I’ve just done the code changes to Proc that are intended to fix this
bug. I’m running it on my machine for a while first, before we let it
go any further – but it definitely fixes up the test case behaviour
quite nicely. I’m not sure what the beta/release cycle will be, but
it should get out there relatively soon.

-David

QNX Training Services
dagibbs@qnx.com

Thank you for the effort. I certainly appreciate it…

-Bill


David Gibbs <> dagibbs@qnx.com> > wrote:
Mike Schneider <> Mike.Schneider@us.heidelberg.com> > wrote:
Dave,
Other than the return value, does alarm() function correctly.
Likewise, is it just the return value from timer_settime() that is
incorrect?

Both from testing, and from looking at the code in Proc – yes, it
is just the return values that are incorrect.

The timers will still function properly, and if you do a “sin rt” you
will see the appropriate values for the timers.

I’ve just done the code changes to Proc that are intended to fix this
bug. I’m running it on my machine for a while first, before we let it
go any further – but it definitely fixes up the test case behaviour
quite nicely. I’m not sure what the beta/release cycle will be, but
it should get out there relatively soon.

-David

QNX Training Services
dagibbs@qnx.com