This issue tracker is closed. Please visit UPPAAL issue tracker at Github instead.

Bug 102 - server.exe crash - memory could not be written
Summary: server.exe crash - memory could not be written
Status: RESOLVED FIXED
Alias: None
Product: UPPAAL
Classification: Unclassified
Component: Engine (show other bugs)
Version: 3.4.5
Hardware: PC Windows 2000
: P2 major
Assignee: Gerd Behrmann
URL:
Depends on:
Blocks:
 
Reported: 2004-05-13 11:46 CEST by Jacob Illum
Modified: 2005-07-05 11:35 CEST (History)
0 users

See Also:
Architecture:


Attachments
The model that makes uppaal crash (20.32 KB, application/xml)
2004-05-13 11:56 CEST, Jacob Illum
Details
Smaller test case (122 bytes, text/plain)
2004-05-13 16:19 CEST, Gerd Behrmann
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jacob Illum 2004-05-13 11:46:26 CEST
This is the error submitted to bug-uppaal by Hans Pettersson - Wed, 12 May 2004 
16:38:02:

The problem is that it seems to write to an undefined memory area (see below.)
---------------------------
server.exe - Application Error
---------------------------
The instruction at "0x00434287" referenced memory at "0x01655380". The memory 
could not be
"written".


Click on OK to terminate the program
Click on CANCEL to debug the program
---------------------------
OK   Cancel
---------------------------

But as far as we can see there should be no such error.
If you run our program as it is sent, then the error will appare in the 
scheduler template, state
S3, just after a few sec in random mode.
The problem seems to have something to do with the "Process_ID" variable.

Can you please take a look at our program and see if this is a bug or just 
something we have missed?

Best Regards

Hans Pettersson
Comment 1 Jacob Illum 2004-05-13 11:56:13 CEST
Created attachment 20 [details]
The model that makes uppaal crash
Comment 2 Gerd Behrmann 2004-05-13 13:51:36 CEST
Confirmed.
Comment 3 Gerd Behrmann 2004-05-13 15:24:50 CEST
This bug is triggered by an out of array condition in a synchronisation label of
the model. The exception that is thrown as a consequence seems to corrupt some
of the stack (but only on Windows). My guess is that this is a compiler bug. 
Comment 4 Gerd Behrmann 2004-05-13 16:19:03 CEST
Created attachment 21 [details]
Smaller test case
Comment 5 Gerd Behrmann 2004-06-04 20:27:27 CEST
I have created a small test case that triggers this problem in the compiler and
submitted it as a bug to the mingw people. Let's see what they do about it.
Comment 6 Gerd Behrmann 2004-06-05 11:35:18 CEST
Here is a link to the bug report at mingw:

https://sourceforge.net/tracker/index.php?func=detail&aid=966724&group_id=2435&atid=102435
Comment 7 Gerd Behrmann 2005-03-22 09:28:30 CET
Reduced severity to major. 

Seems that the mingw people finally noticed my bug report, but no ETA for a fix yet.
Comment 8 Gerd Behrmann 2005-07-05 11:35:30 CEST
The fix for bug 170 also fixes bug 102. 

The compiler is still buggy, but we no longer do dynamic allocation on the stack at this place in the code, 
thus we are no longer affected by the bug.