[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: More Problems



Evan K. Langlois writes:

> I now have programs crashing and giving a BUS ERROR @ PC=7F4

 btw i just noticed the `PC' printed for address errors is not really
the 68k's pc when it happened but the accessed address that caused the
error!  i guess for bus errors its the same...  and i also noticed
bus errors are not printed at all when the process catched SIGBUS.

>...
> It dies right on start-up, but ONLY if I use ^C to kill fsck.  If fsck
> dies early I get Exception 10 and then a BUS ERROR on some programs.

 have you tried the getcwd patch?  maybe its that, i also found it
with fsck...

> What does FSCK have to do with LineA ??   Or am I reading this wrong?
> When MiNT says exception 10, does it mean exception 16 (is it in hex?)

 (its signal 10 == SIGBUS)
> 
> Also, I think the Mintlib's system() call is screwed up.  My entire 
> system locks up when I execute it, and I've used gdb to make sure that
> it was system (the command line passed seems to run but then the whole
> system crashes).  System() gets to _realloc() according to gdb.

 strange.  btw you can gdb' the lib too (make it with `debug'), maybe
you'll find out more then...
> 
> BTW, this was the first time gdb worked for me and showed the source
> lines and such.  I'm not sure why it refused to work when debugging 
> TOSWIN (must have something to do with GEM).

 well if you put the debugger in another GEM (toswin) window the
first traced wind_update will block gdb's window too...  you need
a different tty thats independent from GEM.  (see next message :)
> 
> Oh ... TOSWIN loses less RAM when I use WINX.  I don't remember exactly
> how much less, but it isn't much, but its finally something different.
> My guess is that TOSWIN may have some bad pointer math that overwrites
> some info at the beginning of the memory block (that MiNT uses to tag the
> block of RAM) thus making MiNT think pid 0 (MiNT itself) is the owner.
> Is this a possibility?

 i think this info is only in the proc struct not the block itself
so i'd say unlikely...

 cheers
	Juergen
-- 
J"urgen Lock / nox@jelal.north.de / UUCP: ..!uunet!unido!uniol!jelal!nox
								...ohne Gewehr
PGP public key fingerprint =  8A 18 58 54 03 7B FC 12  1F 8B 63 C7 19 27 CF DA