SRL Archive - S.M.A.R.T. Questions and Answers.

SMART random junk?


Aegis

2012-12-25 14:34:08

This is found in my initial SIMBA folder, as well as a small few within the Scripts' folder. And yes, that totals to 1.29 GB. There's a lot of them.

http://puu.sh/1FcfQ


Not sure if it's related, but here are what some of the error logs read:
Program exception!
Stacktrace:

Exception class: EInvalidOperation
Message: [TCustomForm.SetFocus] SimbaForm:TSimbaForm Can not focus
$00441725
$004412B0
Simba Version: 991



Program exception!
Stacktrace:

Exception class: EThread
Message: Failed to create new thread, code:8
$004413DC
$005CD87A
$00428874
$0042E48F
$005396D1
$00539886
$0040C37A
$004EBC0D
$004DDFB4
$004EED9C
$0040C37A
$004EBC0D
$00568BE7
$0050E94E
$75CD62FA
$75CD6D3A
$75CD965E
Simba Version: 991



Any ideas what could be causing this, or how to fix it? Or is this completely normal..

Benny

2012-12-25 14:47:57

Yeah I got them as well.. I just deleted them.

DannyRS

2012-12-25 14:49:51

From: -Benny
Yeah I got them as well.. I just deleted them.


some kinda cache temp stuff

I got them as well.. I also just deleted

Brandon

2012-12-25 15:03:51

Those have nothing to do with your Simba's crash. It seems your crash is related to some kind of Form Rendering. I'm not sure if you're using Forms though. These files are how Smart does it's MemoryMapping/Sharing to communicate with Simba outside Simba's process.

It's called Inter-Process Communication. I wrote a tutorial on it a while back somewhere in the C++ section. I used the same thing in GLHook except I used local//MapName_ProcessID rather than creating the physical file.

You can't remove the Smart ones while it's running because it locks the permissions and it's in use.

If you don't want them, do what I did and just have Smart remove them in its destructor OR just have Smart not make the files in the first place by creating a Local map.


It's supposed to delete them according to these lines in Main.java:

if (f.exists()) f.delete();
f.createNewFile();
f.deleteOnExit();

DeleteOnExit leaks according to a Java bug report I just saw. Not sure how true that is.