vinsci@nic.funet.fi (Leonard Norrgard) (05/27/91)
The device being debugged is "localser.device" a little hack to connect to communications programs on one machine to each other, one opening unit 0 and the other unit 1. After the more trivial bugs were found, there is this really fun one left. Symptoms: When the comm software exits, we have major output from enforcer and memmung (this being on a 68030 machine). First access is to $deadbeef, yes, dereferring of freed memory, but how and where, not to ask about why...? The interesting thing is that if I within the comm software give up on the serial port first, then from a shell issue flushlibs (causes localser and its unit processes to go away from memory), then exit, everything is fine. This first lead me to beleive that there was something wrong with the _LibClose/_LibExpunge interaction, but... I think I've checked it all. The compiler used is SAS/C 5.10a, and we found one bug related to creating libraries with blink (the fd file must have an odd number of entries, or the last vector never gets initialized...). So, any similar cases seen before? -- Leonard
vinsci@nic.funet.fi (Leonard Norrgard) (06/01/91)
>The device being debugged is "localser.device" a little hack to
__saveds is broken in SAS/C 5.10a. If you have problems using it,
check out what assembly is generated. What happened to me was that it
loaded the base register into A0, which is not exactly where it should
be... Well, turned out __saveds wasn't need anyway...
-- Leonardvinsci@nic.funet.fi (Leonard Norrgard) (06/01/91)
In article <VINSCI.91May31220328@nic.nic.funet.fi> vinsci@nic.funet.fi (Leonard Norrgard) writes: >The device being debugged is "localser.device" a little hack to __saveds is broken in SAS/C 5.10a. If you have problems using it, check out what assembly is generated. What happened to me was that it loaded the base register into A0, which is not exactly where it should be... Well, turned out __saveds wasn't need anyway... BTW, that was when combined with -b0. Also, I hear that if you begin your function declaration with __saveds rather than return type, you're likely to get bad code. While on the subject, void * __saveds is said to generate bad code as well. Or maybe it is the lc call from the shell? :-/ How was it, do they only read news over at SAS, or do they have access at all? Is anybody forwarding all these bugs that get reported in c.s.a.programmer? -- Leonard
fjrei@kbsaar.UUCP (Franz-Josef Reichert) (06/03/91)
In article <VINSCI.91Jun1031912@nic.nic.funet.fi> vinsci@nic.funet.fi (Leonard Norrgard) writes: >In article <VINSCI.91May31220328@nic.nic.funet.fi> vinsci@nic.funet.fi (Leonard Norrgard) writes: > >The device being debugged is "localser.device" a little hack to > > __saveds is broken in SAS/C 5.10a. If you have problems using it, > check out what assembly is generated. What happened to me was that it > loaded the base register into A0, which is not exactly where it should > be... Well, turned out __saveds wasn't need anyway... > >BTW, that was when combined with -b0. Also, I hear that if you begin >your function declaration with __saveds rather than return type, >you're likely to get bad code. While on the subject, void * __saveds >is said to generate bad code as well. Or maybe it is the lc call from >the shell? :-/ Please, can you provide a small piece of sample code which shows this bug _reproducable_? >-- Leonard -- Best regards, Franz-Josef Reichert VOICE: +49 6805 7417 Kuchlingerstrasse 13 UUCP: ...uunet!cbmvax!cbmehq!cbmger!kbsaar!fjrei D-6601 Kleinblittersdorf GERMANY