 |
| Zerberus 2007-12-18 16:08:31 | 4.44b does terminate (crash) after some time. In the muon1 folder I still see a recent autosave. Now going back to 4.43d. |
| Stephen Brooks 2007-12-18 16:18:14 | 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. |
| Zerberus 2007-12-18 16:29:04 | 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). |
| Stephen Brooks 2007-12-18 16:36:09 | 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. |
| Zerberus 2007-12-18 16:42:41 | 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 |
| Stephen Brooks 2007-12-19 10:33:53 | The piece of information I actually need is your e-mail address (you can send me an e-mail at sb stephenbrooks.org so I'll have it without posting it on the forum). |
| Zerberus 2007-12-19 14:32:25 | Thought I entered it in my profile, sorry. Used 'muon1 debug' as title. |
| Zerberus 2007-12-20 14:36:17 | 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. |
| Zerberus 2007-12-20 17:09:47 | 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. |
| Zerberus 2007-12-21 21:37:22 | muon1 4.44c debug version Icc runtime: GP fault. Stack trace 0 collideparticle[21] c:\sjb39\muon1\muon1.c 287 1 Simulation_advance_t[24] c:\sjb39\muon1\muon1.c 353 2 Simulation_advance[49] c:\sjb39\muon1\muon1.c 434 3 SBCLIB_main2 [103] c:\sjb39\muon1\muon1.c 148 4 WinMain[0] c:\sjb39\muon1\muon1.c 45 Current instruction: 0x10b9b54 |
| Stephen Brooks 2007-12-21 21:43:42 | 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. |
| Zerberus 2007-12-21 22:13:31 | Well, I'll run 4.43d a few days more, I think. Happy holidays everyone! |
| Zerberus 2008-01-03 22:32:29 | Are there any news regarding 4.44c? |
| Stephen Brooks 2008-01-04 07:46:58 | 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? |
| Zerberus 2008-01-04 08:06:20 | 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. |
| Stephen Brooks 2008-01-04 08:54:17 | 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. |
| Zerberus 2008-01-04 10:27:57 | 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? |
| Thor263 2008-01-07 15:51:13 | 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? |
| Zerberus 2008-01-08 06:52:04 | 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? |
| Stephen Brooks 2008-01-08 15:12:28 | 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. |
| Stephen Brooks 2008-01-08 16:40:19 | 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. |
| Zerberus 2008-01-12 16:40:30 | 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. |
