|4.44b does terminate (crash) after some time. In the muon1 folder I still see a recent autosave. Now going back to 4.43d.|
|Yeah, took it down from the main site as it clearly wasn't working well enough. 4.43d is a good idea for now, it will crunch exclusively on PhaseRotEb1.|
There'll be a 4.44c later this week. I think I'll get to the bottom of the serious issues at least.
|Wouldn't it be a good idea to have a debug version to find out WHY it crashed?|
Dr. Watson only tells me it's a c0000005 (Access violation).
|There's the possibility of a knock-on effect from things I am debugging here that might mean the overall stability of the code is better when they are fixed. But I can e-mail you a debugging version in case it is a totally new bug.|
|From what I know it's something with Autosave. It crashes at the end of the simulation (or nearly the end) and the autosave file is not deleted at all. Re-running the client from that autosave leads to a further crash and the autosave is, again, not deleted.|
Wait, inside the Dr Watson log, I found the following line - could that be from muon?
924 Error 0xD0000022
|The piece of information I actually need is your e-mail address (you can send me an e-mail at sbstephenbrooks.org so I'll have it without posting it on the forum).|
|Thought I entered it in my profile, sorry. Used 'muon1 debug' as title.|
|Did a few tests yesterday and had so far no more crashes. Seems to be running great. Of course only long-term usage will definitely reveal it's stability or instability.|
I guess I'll now migrate to 4.44c.
|Uh-oh, I spoke too soon. Crashes still occour. I've isolated an auto.sav that crashes everytime. Now I need a debug version, so far I only get a report from DrWatson that reveals nothing besides c0000005 Access violation.|
|muon1 4.44c debug version|
Icc runtime: GP fault. Stack trace
0 collideparticle c:\sjb39\muon1\muon1.c 287
1 Simulation_advance_t c:\sjb39\muon1\muon1.c 353
2 Simulation_advance c:\sjb39\muon1\muon1.c 434
3 SBCLIB_main2  c:\sjb39\muon1\muon1.c 148
4 WinMain c:\sjb39\muon1\muon1.c 45
Current instruction: 0x10b9b54
|Well, I can see where that is. It's looking through the nearby cells to a particle to check if any have some scattering material (none so far do in our simulations). I did change the nearby cell detection code recently, perhaps that could have caused an intermittant error like this.|
I'll be back in the laboratory on January 2nd where I have all the code set up to look at thsi.
|Well, I'll run 4.43d a few days more, I think. Happy holidays everyone!|
|Are there any news regarding 4.44c?|
|Oh, I seem to had forgotten about this thread. I'm not really sure I'll be able to do anything if this requires a specific auto.sav file. Does getting rid of that file stop your version from crashing at all?|
|Two days ago I switched from 4.43d to 4.44c on my laptop. I have Autosave disabled and it has not crashed since.|
Everytime it crashed earlier with Autosave ON, there always was an auto.sav left behind. I even once had an issue with a simulation starting at 50.0 ns instead of 0.00 (it crashed later, too)!
The bug seems to be related to Autosave.
|It shouldn't even read the autosave file except when the program starts, the rest of the time it will just be writing it. Are the crashes only immediately after starting Muon1? My installations have been fine except they appear to have a memory leak as the RAM usage grows by about 40MB each day.|
|No, the crashes don't immediately happen after the start. For the most time, the simulation runs for quite awhile. With the background process, I only nottice when CPU usage drops. Did you check the nearby cell detection code so far?|
|I too am having intermittent crashes that seem to go away when I disable Autosave w/ 4.44c. Would it be helpful if I ran the debug version?|
|After running for a few days with Autosave disabled I can draw one definite conclusion: With Autosave disabled there are no more crashes. But even the creation of Autosave files leads to the crashes. Maybe it is a bug with muon's filehandling and muon crashes on the attempt to overwrite an autosave?|
|I've found and fixed a memory leak here, have a smaller one to find, then there are also crashes here sometimes in background mode. So perhaps I'm closer to seeing this problem.|
I'm beginning to think it's a memory allocation problem that causes a crash later on in something like autosave when the appropriate memory structures are looked at again.
|I've replicated and now apparently solved a crash at collideparticle line 287, which was preventing me from loading saved files. The initialisation of the material field for some components was not complete.|
|I've updated to 4.44d and had no more crashes since. Awesome.|
Just some things remain:
- Would it be possible to use 16bit as color depth for the graphical client? With the 8bit modes all components randomly change colors every few seconds. ('Palette shifting'). Happens on more than one of my systems. Suspecting that ATI no longer cares for 256 colors...
- commandline option '-txttobin' does not work for me, crashes everytime. I guess '-bintotxt' is the same, but could not test that.