When running a specific script in batch mode, a Stack Underflow exception is generated and doors.exe experiences a ACCESS_VIOLATION exception. The script is quite simple:
string lStringAbove = "This is a string.";
void StringTest()
{
print lStringAbove "\n";
return;
}
void ModuleOpen()
{
print "Opening the module\n";
Module lMod = read("modulepath");
print "Closing the module\n";
close(lMod);
return;
}
StringTest();
ModuleOpen();
Object o1;
Object o2;
Object o3;
string st1;
string st2;
string st3;
StringTest();
Where "modulepath" is a path to a readable module. In the DOORs UI this runs as expected and produces the output: This is a string. Opening the module Closing the module This is a string. But in batch mode: This is a string. Opening the module DOORS: **** Translating a structured exception **** DOORS: Version 9.6.1.3, build number 96245, built on Jun 1 2015 22:24:17. DOORS: Microsoft Windows 7 Professional Service Pack 1 (build 7601), 64-bit DOORS: DOORS: 47 percent of memory is in use. DOORS: There are 16680152 total Kbytes of physical memory. DOORS: There are 8765248 free Kbytes of physical memory. DOORS: There are 33358444 total Kbytes of paging file. DOORS: There are 23618048 free Kbytes of paging file. DOORS: There are ffffff80 total Kbytes of virtual memory. DOORS: There are fff7da6c free Kbytes of virtual memory. DOORS: argv[0]: C:\Program Files\IBM\Rational\DOORS\9.6\bin\doors.exe DOORS: argv[1]: -o DOORS: argv[2]: r DOORS: argv[3]: -O DOORS: argv[4]: r DOORS: argv[5]: -data DOORS: argv[6]: 36009@doors_f5_vip.tsg.ge.com DOORS: argv[7]: -u DOORS: argv[8]: <USERNAME> DOORS: argv[9]: -P DOORS: argv[10]: <PASSWORD> DOORS: argv[11]: -b DOORS: argv[12]: <PATH_TO_DXL> DOORS: Exception timestamp: 01/09/2016 at 17:50:51 DOORS: doors.exe caused an EXCEPTION_ACCESS_VIOLATION in module doors.exe at 00000000407FD63B DOORS: 0x000001407fd63b doors.exe 0x000001407fc99b doors.exe 0x00000140807a16 doors.exe 0x00000140807d7c doors.exe 0x00000140a9b2ac doors.exe 0x00000140535c9f doors.exe 0x00000140541489 doors.exe 0x0000014001cbf7 doors.exe 0x0000014001ddbc doors.exe 0x000000774959bd kernel32.dll, BaseThreadInitThunk()+00000013 byte(s) 0x000000775ca2e1 ntdll.dll, RtlUserThreadStart()+00000033 byte(s) DOORS: **** end of event **** DOORS: Writing exception details... Where <USERNAME>, <PASSWORD>, and <PATH_TO_DXL> are the parameters with the path to the file and the user login info which has been redacted.
Has anyone else experienced this? This is in the DOORS 9.6 x64 client on Windows 7. ryan_s - Thu Sep 01 18:04:31 EDT 2016 |
Re: Unhandled Structured Exception In Batch Mode but not User Mode I have not seen this before, but as a wild guess: perhaps your default view is in some way not compatible with the batch mode, there might be weird dxl layout columns. Try to open the module with the Standard view using the third read - parameter
Module read(string name
[,bool disp[, bool loadStandardView]])
perrhaps this helps... |
Re: Unhandled Structured Exception In Batch Mode but not User Mode Does the error occur everytime or just occasionaly |
Re: Unhandled Structured Exception In Batch Mode but not User Mode The DXL code looks fine, I would look in the following places: - DXL Attributes / DXL Layout - Triggers - Client Customizations, changes to the start scripts, etc. So you can go along the following path, to see, when the error will disappear: - Try reading a newly created module instead. See if the error goes away (get rid of layout / DXL attribute errors) - If this does not help, try disabling triggers (login as admin with the disable triggers argument or go to a different database without triggers) - If the error persists, then you need to look inside your client customizations. For this come back to the post if the error persists after trying the above. Regards, Mathias |
Re: Unhandled Structured Exception In Batch Mode but not User Mode DOORSHAM - Fri Sep 02 04:09:38 EDT 2016 Does the error occur everytime or just occasionaly This occurs every time I run it in batch mode at the same line of code, where the module is opened and assigned to a variable. |
Re: Unhandled Structured Exception In Batch Mode but not User Mode Mathias Mamsch - Fri Sep 02 05:10:57 EDT 2016 The DXL code looks fine, I would look in the following places: - DXL Attributes / DXL Layout - Triggers - Client Customizations, changes to the start scripts, etc. So you can go along the following path, to see, when the error will disappear: - Try reading a newly created module instead. See if the error goes away (get rid of layout / DXL attribute errors) - If this does not help, try disabling triggers (login as admin with the disable triggers argument or go to a different database without triggers) - If the error persists, then you need to look inside your client customizations. For this come back to the post if the error persists after trying the above. Regards, Mathias I'll be checking this shortly. As far as I know the module I am running against has no DXL Attributes or Triggers assigned to it. Interestingly enough, if I move these three lines: Object o1; Object o2; Object o3; string st1; string st2; string st3; To the top of the file, the code executes properly. |
Re: Unhandled Structured Exception In Batch Mode but not User Mode ryan_s - Fri Sep 02 11:37:10 EDT 2016 I'll be checking this shortly. As far as I know the module I am running against has no DXL Attributes or Triggers assigned to it. Interestingly enough, if I move these three lines: Object o1; Object o2; Object o3; string st1; string st2; string st3; To the top of the file, the code executes properly. I remember something else. Batch executes at TOP DXL context. I remember that it helped to wrap the code in curly braces.
{
/// Your code
}
Don't know why. Probably some bug in the parser. Regards, Mathias |
Re: Unhandled Structured Exception In Batch Mode but not User Mode Mathias Mamsch - Fri Sep 02 12:08:12 EDT 2016 I remember something else. Batch executes at TOP DXL context. I remember that it helped to wrap the code in curly braces.
{
/// Your code
}
Don't know why. Probably some bug in the parser. Regards, Mathias That fixed it! Simply wrapping the entire script in a code block eliminated the issue completely. Such an odd parser bug. Thanks! |