Using abort inside a chain of functions.

Kye · 2009-12-18 05:16

Hey guys, I've been making some good progress on my FAT driver, however I'm expierencing a little problem that I can't quite figure out. Its with the code below.

unformatName(listFind(listDotDotDot(directoryName, formatName(directoryName)), @directoryNotFound))

When I execute the piece of above code everything works fine as long as no abort is called. However, if the "listfind" function in there calls an abort some really wierd stuff happens.

Its like there's some sort of delayed crash. The abort is handled okay for like a second as it starts printing out some·random characters·and then you get the fun effects of either the screen being covered in·garbage·and or the chip resetting as the main memory is overwritten.

I'm only using four processors right now, one for vga, one for keyboard and mouse, one for SD card acess, and one for the spin code.

...

So I've tried increassing the amout of extra ram space free for the stack but that doesn't seem to be the problem. The problem does disapear if I make the function call like this however:

listFind(listDotDotDot(directoryName, formatName(directoryName)), @directoryNotFound)

But the unformat name function only runs this piece of code which should all be ignored under an abort situation.

PRI unformatName(name) ' 4 Stack Longs
  if(name)    
    bytefill(@DIRName, " ", 12)
    bytemove(@DIRName, name, 8)
    repeat while(DIRName[noparse][[/noparse]++result] <> " ")
    DIRName[noparse][[/noparse]result++] := "."
    bytemove(@DIRName[noparse][[/noparse]result], @byte[noparse][[/noparse]name][noparse][[/noparse]8], 3)
    if(DIRName[noparse][[/noparse]result] == " ")
      DIRName[noparse][[/noparse]--result] := " "
  
    return @DIRName

And even if the code would be executed it should not cause a system crash.

EDIT (Commenting out all the code in the above function does not fix the problem like removing the function call does... must be problem with call stack or something.) ***

...

Is there any thing I should know about abort? Could there be a bug in the spin interpreter with it?

I'm posting the code I was using below. Just modify the FAT engine's pins int he constant section of the code(very top) and try running the comman "cd <name>" on a file that does not exist and you'll see the error.

You'll need a keyboard and vga monitor to run the Main file.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Post Edited (Kye) : 12/18/2009 5:25:24 AM GMT

Mike Green · 2009-12-18 05:46

Abort seems to work fine. All of the FemtoBasic versions use it for reporting an error from deep in recursion and I've never seen a problem with it. You do have to be careful in catching the abort in that some routines might leave global variables in unstable states. Check all the places where an abort can be invoked, then check all the places where it might be caught ("\").

Kye · 2009-12-18 15:35

Mike what do you mean by leave global variables in unstable states?

This error isn't just the spin interpreter exiting... It completely goes haywire and starts to overwrite system memory with random garbage.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Kye · 2009-12-18 15:58

Wait, I've narrowed the error down to:

    result := \shellCommands(result)   
    bmp.printCharacters(result)

The above code works... however the below code does not,

bmp.printCharacters(\shellCommands(result))

I don't see the difference is using either notation except the below is the most efficent. But it crashes everything.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Mike Green · 2009-12-18 16:20

The second example uses another couple of stack locations.

Kye · 2009-12-18 16:25

Yes, but why would one crash vs the other? What possible things could go wrong?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

rokicki · 2009-12-19 00:03

Are you sure bmp.printCharacters() is prepared to handle the "abort" error code from shellCommands?
(Because it *will* be called, even if shellCommands() fails. And if printCharacters() is expecting a buffer
pointer instead of an error code, that can cause failures like you describe.)

I can't get your scenario to fail over here when printCharacters() is expecting an abort code.

rokicki · 2009-12-19 00:47

Looking at printCharacters, it's clear that that routine is not prepared to handle an abort code, or at
least to distinguish a true/false return from an error string.

Is it possible your routine is running successfully, thus returning true (-1), and then -1 is being
interpreted at a buffer address (which will not work)?

Kye · 2009-12-19 03:00

I tried sorting that out by switching to a full serial terminal for everything.

Here's the code using only a serial terminal.

The error still occurs however, it will crash 100% if you try to "cd" into a non existant directory. Its actually pretty weird. If you put abort traps in the cd and attrib functions and then make them never return the code does not crash (when it crahsed using the vga terminal the screen blows up). However, after using abort traps if you still let the functions return then everything fails.

The weird thing is that different aborts have different problems that occur with them. I can't put my finger on what exactly is the problem. I have notices that if you do:

var := \function

everything works fine. But I really want to know know exactly why:

function1(\function2)

can fail. I'll continue to debug tommorrow.

...

As an answer to your questions rokicki, the rountines only return a pointer to a string as an error code or 0. A pointer value of 0 should be harmless since at the 0th location at 80_000_000mhz the 0th byte is 0 thus causing any stringsize function to return 0 thus nothing should be printed.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Post Edited (Kye) : 12/19/2009 3:07:54 AM GMT

Using abort inside a chain of functions.

Comments