My script crashes!

Hi!

I have written a export script from doors to excel. The thing is that this script exports all modules in a folder to excel worksheets. All modules have the same view. The problem now is, I get after exporting three modules this crash:

DOORS: **** Translating a structured exception ****
DOORS: Version 9.5.1.2, build number 95088, built on Aug 13 2013 22:09:47.
DOORS: Microsoft Windows 7 Enterprise Edition Service Pack 1 (build 7601), 64-bit
DOORS: DOORS: 41 percent of memory is in use.
DOORS: There are 4194303 total Kbytes of physical memory.
DOORS: There are 4194303 free Kbytes of physical memory.
DOORS: There are 4194303 total Kbytes of paging file.
DOORS: There are 4194303 free Kbytes of paging file.
DOORS: There are 3fff80 total Kbytes of virtual memory.
DOORS: There are 39acac free Kbytes of virtual memory.

DOORS: argv[0]: C:\Program Files (x86)\IBM\Rational\DOORS\9.5\bin\doors.exe
DOORS: Exception timestamp: 08/09/2015 at 10:24:16
DOORS: doors.exe caused an EXCEPTION_ACCESS_VIOLATION in module <UNKNOWN> at 0023:06A57732
DOORS: Stack trace string not available
DOORS: 0023:007031C0 (0x485AEB07 0x100127F7 0x100127EC 0x0D8C0DF4) doors.exe
DOORS: 0023:00686820 (0x00000008 0x0D8C0DF4 0x000032B0 0x00000000) doors.exe
DOORS: 0023:76B80D4D (0x059937A8 0x00070648 0x000000B9 0x00000000) USER32.dll, CallWindowProcW()+0027 byte(s)
DOORS: 0023:005BE89B (0x059937A8 0x00070648 0x000000B9 0x00000000) doors.exe
DOORS: 0023:005D647D (0x00070648 0x485AEB07 0x0018E788 0x0068D44D) doors.exe
DOORS: 0023:76B762FA (0x0C90B97C 0x0018E7E0 0x0000000B 0x0018E7E0) USER32.dll, gapfnScSendMessage()+0818 byte(s)
DOORS: 0023:6FB60475 (0x0C90B97C 0x0000000F 0x0018E7E0 0x0000000B) MSVCR80.dll, memcpy_s()+0072 byte(s)
DOORS: 0023:6F7A1201 (0x0C90B97C 0x0000000F 0x6F7A3958 0x0000000B) MSVCP80.dll, std::char_traits<char>::_Copy_s()+0021 byte(s)
DOORS: 0023:6F7A394D (0x0018E7DC 0x00000000 0xFFFFFFFF 0x0C90B970) MSVCP80.dll, std::basic_string<char,std::char_traits<char>,std::allocator<char> >::assign()+0126 byte(s)
DOORS: 0023:6F7A49EA (0x00000026 0x00464C5C 0x485AEA97 0x0C90DEA0) MSVCP80.dll, std::basic_string<char,std::char_traits<char>,std::allocator<char> >::basic_string<char,std::char_traits<char>,std::allocator<char> >()+0032 byte(s)
DOORS: 0023:00464C4F (0xC9850CEC 0xC9330E77 0x512CC96B 0xFB3B1CE8) doors.exe
DOORS: **** end of event ****
DOORS: Writing exception details...
DOORS: Exception details have been written to: C:\Users\amehto4\AppData\Local\Temp\DOORS-95088-2015_09_08-10_24_17-576-8000.dmp

In the last line of the print you can read, that a dumpfile was written, but I can't open the dumpfile with the windows texteditor or so! Which programm I need to open this dumpfile? Furthermore, I can't interprete this crash dump above and I don't know why the script crashes exactly after exporting three modules! Can anybody help me? Thank you!

Re: My script crashes!
Mathias Mamsch - Tue Sep 08 12:47:19 EDT 2015

I am not sure if you can get viable information from this traceback. Also from just this traceback without any code to go on you should not expect a lot of feedback. There could be any number of reasons for this error. Judging from the traceback:

This is an access violalation, that was sent from a DXL GUI code part (sendMessage). Most likely this happens, because the DOORS client sends a window message to a closed or destroyed dialog or dialog part. This can happen e.g. in the following cases:

- You called destroy from a callback. Never call destroy from a callback.

- You called destroy on a dialog that was shown with show(DB). Only use hide.

- Your DXL or DOORS is trying to interact with a dialog that was parented to the current module, but the current module was closed and therefore the dialog invalidated by DOORS: In this case parent the dialog to the dbExplorer.

For fixing the error I would start to add dbExplorer as the parent of the dialog and removing any destroy or hide statements inside the dialog. See if this fixes the error.

Hope this helps, regards, Mathias

Re: My script crashes!
llandale - Tue Sep 08 17:26:46 EDT 2015

Surely there is also a DXL error in the DXL window?

Re: My script crashes!
AlexTidmarsh - Thu Sep 10 03:06:42 EDT 2015

These outright crash dumps are always unhelpful.  Especially when they cause DOORS to fail without a DXL fault statement in the DXL window.  I find I have to resort to other debug methods to track down errors when this happens.  I have "an approach" that tends to help with debugging that is something like as follows:

1. If the crash happens as soon as the script is loaded (which doesn't appear to be true in your case), then the error is most likely to be that the DXL interpreter has crashed - probably due to similar but incompatible subroutine headers being encountered.  In that case: "divide and conquer" by excluding new scripts until you can deduce which script is causing the problem.  Then do the same with the text in that script.  If there is a subroutine header clash, renaming the culprit, or adding a dummy parameter can often verify (and eliminate) the problem.  If you own BOTH the clashing routines, try simply defining them in the reverse order - believe it or not, this often works if there are only TWO such overloads.  With three clashing overloads, then you will be fighting with the interpreter every inch of the way - so changing the parameters radically or renaming one of the overloads is often a better bet.  Avoid overloading PERMS, unless you really know what you are doing and why.  If the crash does occur when loading a script, and it IS a subroutine clash, then it is very probable that you have overloaded a perm, causing code other than your own to crash - which is very hard to then debug.

2. If the crash happens at "runtime" (which appears to be true in your case) then add logging statements to your code (logging to the DXL window if DOORS stays alive, or to a file or 3rd-party logger if DOORS falls over entirely).   I have my own system that sends logging real-time to a 3rd party logger called CodeSite - I had to write some software to make this happen, but it has proved invaluable.   Use these logging statements to narrow down the "last statement" executed before things went "pear-shaped" - again, don't do this by writing thousands of log statements - use "divide and conquer".    Once you know which script and which routine is failing to run, - or better, which script or routine is crashing -  you can try analysing the code (a read-through), or replacing parts of it with alternatives (dummy code, alternative ways of achieving the same thing) or simply removing lines, until the crash is replaced either by a working system or a more helpful error report from DXL (this actually happens in many cases!).

Runtime crashes often result from "typical" scenarios:
    Routines working on "abandoned" buffers, skip-lists, etc. because they have not been properly re-created or deleted and thus have unexpected content.  DXL does detect items that have never been initialised, but can't tell when the structure contains something other than the 0x87654321 hexadecimal "unassigned" value but is nonetheless invalid.
    (As Mathias says) code that tries to talk to a dialog that has in fact disappeared.
    Routines that incorrectly handle the tempStringOf perm - forgetting that this really is a temporary string!

    Routines that have parameters passed by reference (&x) that are overloaded by routines that have similar parameters not passed by reference (x).

    Falling foul of DXL's piss-poor namespace management and redefining "global" or "perm" definitions, causing unrelated code to fail.
    And a thousand others - not actually worth listing here: better to know what code is in your failing subroutine (once you have narrowed it down) and then research this forum for the idiosyncrasies that others have already discovered.
 

If you can eventually narrow it down to a single routine, but the error is still unfathomable, then try isolating that routine "in abstract" in the DXL execution window - and test it with various parameter values "in harness".  Indeed, once you have narrowed down the error to existing within a few lines of code, you can post it to the forum and ask if anyone else has encountered problems with similar scripts or perms.   But that is really only a viable option once you have done the groundwork and have isolated the problem down to a few lines of code.  The fewer the better.

I feel for you:  a DXL fault that produces a crash dump is (a) extremely hard to debug and (b) quite often the result of a "bug" in DXL - something undocumented or not working properly and (c) just as often the result of "simple" errors such as the ones indicated above.   But when there are few clues - you have to approach it by creating your own clues!

Good luck.

Re: My script crashes!
AlexTidmarsh - Thu Sep 10 03:31:13 EDT 2015

Incidentally - for any forum readers who are relative software engineering novices - "divide and conquer" works best as a binary search, if you can see how to implement one.  Binary search then itself works best if you RELIGIOUSLY stick to the rules.

Find where you can apply the search
Eliminate EXACTLY HALF of the variants
Disregard those variants that have no effect on the bug if eliminated and (best) bring them back into play
Always halve the remaining suspects

This narrows down the culprit in the minimum number of trails.

e.g.  1024 suspects can be reduced to a single suspect in just 10 tests.

When it isn't feasible to "REMOVE" code as your elimination approach, try to work out how to eliminate by deduction (e.g. using logging statements) and then apply the binary search to that instead.  Quite often you can eliminate suspects by providing a minimal number of logging statements to identify code that is "working" and code that is "failing".

Be warned: divide and conquer also works best if your code is modular, can be replaced by "dummy code" without causing the whole edifice to crumble, or indeed by taking modules out of context and testing them in harness".   If you tend to write 1,000 line subroutines - then you are your own worst enemy.

Final thought:  If you have code that has a bad track record for bugs, give serious consideration to the idea that it is "bad code" that needs to be thrown away and rewritten from scratch - using modularity, harness testing and logging as your guide that each part of that code is doing what is expected of it.

Thus endeth this primer.

Re: My script crashes!
Wolfgang Uhr - Thu Sep 10 04:25:59 EDT 2015

Hi

>  Which programm I need to open this dumpfile?

By the way there are some dump files in windows and it may be that this are the same file types.

http://stackoverflow.com/questions/158534/reading-a-windows-dmp-file

But even it the problem is inside such a file, it is a long way.

Wolfgang

Re: My script crashes!
llandale - Sat Sep 12 16:18:29 EDT 2015

Actually a rigorous "binary search" is only the "best" approach when you have no idea of the affected distribution.  Nobody uses a "binary search" when looking in a hard dictionary for "apple" since we know it is near the beginning.  Likewise in this case, you probably have an idea where the error occurs and should be looking there.  Having your first split at 5/8 and your next at 3/4 is perfectly reasonable if it narrows down the sample size.

Also, even when using a binary search it doesn't matter if you split "exactly" in half or not.  Going 1/4-3/4 split once doesn't disrupt the search.

-Louie

Re: My script crashes!
AlexTidmarsh - Sun Sep 13 19:06:16 EDT 2015

Louie, I agree totally with your first comment.  In so far that it applies to searching in a SORTED list - as per Donald Knuth's algorithm and you are looking for an English word in an English dictionary.   (How convenient - what sort of bugs do you usually have?)

But joking aside...

If you know something about the relationship of the "value" to its "dataset", then you can use that as a heuristic.  In that case, rigor in your "search algorithm" is probably less than relevant.

This is about when you do not have any convenient debugging clues.  Such as when you get a total crash of the DXL interpreter or, worse, a shutdown of DOORS, and especially when it happens without any other visible clues.  And I include in this, start-up crashes when a DXL script is read, random crashes that do not appear related to what was executing, and crashes that occur when there is no visible output (in, say, silent batch scripts).  Worse still, it might only occur in code you wrote and tested as ok three months ago, or code that you didn't even contribute yourself.   It might even be code that works fine in isolation, but crashes DOORS when you include it in a deployed system with other people's code (oh how often that has happened!).  In other words, you really do have to hunt for the DXL file or subroutine that is causing the stack-dump crash and have no basis for concluding up front which one it might be.  This doesn't happen that often, but it does happen - and it can be a painful showstopper when it does.

Incidentally, Binary Elimination is probably a better term than "Binary Search", as nothing is "sorted" when bug-hunting and Knuth coined the phrase for an algorithm specific to sorted lists.  But that doesn't mean you can't apply the math of binary search to elimination tests.

So I don't agree with your second comment (about not disrupting a BINARY elimination): anything but a 50:50 split is suboptimal - the BINARY split (50:50 recursively) ensures a minimal number of tests - that is how its maths works.  What you are suggesting is that you can get away with a different split if you have enough heuristics to make an "educated" guess as to where the thing you are searching for lies.  In other words, what you say in your first comment (about apples) is yet again correct!  If you have no clue where what you are searching for lies, then you cannot apply a heuristic guess, only a "random" one, which statistically is more likely to be wrong and thus will lead to more than the optimal number of tests - so anything other than exact BINARY splitting is suboptimal unless you are lucky more than 50% of the time.

Again - it's less important if all you are faced with is a 10-line piece of code that crashes DOORS in isolation.  But it is important if you have a system with thousands of lines of code and many contributors, all of whom deny responsibility exactly because their code DID work in isolation.

P.S.  This binary elimination approach is also the recommended way of using MSCONFIG in Windows to track down and eliminate services and start-ups that cause Windows applications to malfunction.  So it is already a well-known and generally accepted approach to debugging "the unknown".  In that example, you also usually exclude the least likely candidates (Microsoft's own services) from your search set before you start.  So see the description on http://www.makeuseof.com/tag/how-to-troubleshoot-your-windows-with-the-msconfig-utility/ as an example of this debugging approach (the binary search bit is at the very end of the article).  The trick is then to work out how best to apply the same sort of approach to your candidate set of DXL files and DXL subroutines.

Re: My script crashes!
tobi_mehrl - Mon Sep 14 09:15:47 EDT 2015

Hi,

I have searched for a failure in my code. I have now found, that the use function "closeIfNonNull" is used in my own function setCell() and obviously it makes problems.

This "closeIfNonNull"-function is declared in C:\...\dxl\utils\ole.inc

I have attached my own function "setCell()" and the oleCloseAutoObject function in which is this closeIfnonNull()-function used. I think there is a problem with the oleCloseAutoObject function from ole functions.

Do anybody know any helpful ideas?

Re: My script crashes!
AlexTidmarsh - Mon Sep 14 18:41:58 EDT 2015

Initial thoughts:   I immediately have to ask: what and where is objCell?
 

It is not a parameter to your routine and thus must be a global, which means its initial value when entering your subroutine is always going to be suspect.  From the "semantics" of the code I would deduce that it is meant to be an OleAutoObj.  I have used these a lot in my own code, for instance in the interface to CodeSite I mentioned earlier.  And these can cause havoc if encountered in an unexpected state in your code.  So first off, I'd find where it is declared and make sure it is correctly initialised:  with OleAutoObj types, it is NEVER a good idea to rely upon auto-declare.

I'd then search all the DXL code you have in the system and discover who else uses this global and how.   What is its lifecycle?   Who creates it and when?   Who uses it and when?   Who ultimately destroys it and when?

For instance - look at the object's construction:

       OleAutoObj objCell = null  // Declared as null and created / destroyed elsewhere
or

      OleAutoObj objCell = oleCreate(....)  // Created here, but destroyed elsewhere (be careful about the lifecycle!)

or

      OleAutoObj objCell = SomeFunction(....)  // Created and returned by SomeFunction, but destroyed elsewhere (lifecycle?)

or

      OleAutoObj objCell

      SomeFunction( objCell, ... )  // Created in SomeFunction by using a reference variable (Check that it IS passed by reference!)

Similarly, check who destroys it and when.  Make sure it is destroyed and not just closed!
 

After a bit more thought:   I would have concerns about your closeIfNonNull strategy, since you do not actually ensure the object is a null, you only close it.  Check that it does render the variable to a recognisable null, don't just assume it does.  Try adding the line objCell=null immediately after and see if that makes a difference to the crashing.
 

Hope this may help.  If not, then no doubt others will chip in who have already experienced writing Excel exporting routines (I haven't) and will look more to the semantics of your routine.  I've merely applied a "suspicions" approach, looking for the most likely candidate for an outright DOORS crash.
 

To demonstrate what I mean about ENSURING destruction - here's an excerpt from my logging code base, where I ensure a "logger" ole object is truly destroyed:

 

//-------------------------------------
   void CloseLogger(OleAutoObj &Logger)
//-------------------------------------
// Every call to StartLogger() needs to be matched with a corresponding call to CloseLogger with the same logger variable!
   {
      if (null Logger) return
      oleCloseAutoObject Logger
      logger = null
   }

At some point, I too had encountered outright crashes of DOORS, until I'd adopted this strategy of pairing constructors and destructors and ensuring they were called in a properly managed lifecycle - and guaranteeing that the OLE object variable would always be NULL when the object was closed.  So my guess is that this may lie at the root of your problem.

P.S.   Remember that there is a difference between UNINITIALISED and NULL.   Don't assume that any perm will treat an uninitialized variable as a null - that is a leap of faith too far.  Therefore, Always, Always, Always, make sure that a variable is either constructed or set to an explicit null within either its declaration, or within a few lines after its declaration (the former is best).  And I will repeat: NEVER rely on Auto Declare - it is a pure evil tool of the Devil.
 

P.P.S  You can test whether the DXL Interpreter "thinks" you meant to auto-declare a variable by turning Auto-Declare OFF when starting DOORS.  See elsewhere on this forum on how to do this (search for auto declare).  Unfortunately leaving it switched off isn't always possible so because much code already out there depends on this (abhorrent) practice.  There are many lazy programmers out there.


 Let us know how you get on. 

Re: My script crashes!
tobi_mehrl - Tue Sep 15 03:14:49 EDT 2015

Hi Alex,

thank you for your request. I have read it. You are ask where is this objCell declared. "objCell" is a global variable from type OleAutoObj and is initialised with "null".

You write: "After a bit more thought:   I would have concerns about your closeIfNonNull strategy, since you do not actually ensure the object is a null, you only close it.  Check that it does render the variable to a recognisable null, don't just assume it does.  Try adding the line objCell=null immediately after and see if that makes a difference to the crashing."

Yes this is right. This strategy don't come from me. I must adapt a existing DXL code, but this is not that problem. Before your answer tomorrow, I have inserted a if-statement around the function closeIfNonNull in this setCell-function, like this:

if(!null(objCell))
{
    closeIfNonNull objCell
}

This shows the effect, that a lot more of modules were exported to excel, but this morning I get a similar also unspecified crash from doors.

You also write: "Try adding the line objCell=null immediately after and see if that makes a difference to the crashing." Where do you mean I should insert this line?

Re: My script crashes!
Wolfgang Uhr - Tue Sep 15 04:34:14 EDT 2015

Hi

if(!null(objCell)) {
   closeIfNonNull objCell

   objCell = null
}

Best regards

Wolfgang

Re: My script crashes!
tobi_mehrl - Tue Sep 15 05:03:35 EDT 2015

Hi,

spooky. The script from yesterday has exported 6 modules and then comes a failure. Today the crash comes after 1 module! I don't know where is the failure.

The problem is still the same. The DXL action window says the problem is in line with the closeIfNonNull function. What can I do?

I have also searched for Auto-Declare off, but I don't understand how it will goes, to turn off auto-declare. Have I run a script?

Now, only a few lines for the objCell variable. This variable includes as content the content from the current attribut content from the opened doors module. This content from objCell variable is sended to a oleVariable which writes in excel cell.

PS: I have now attached my complete DXL script. I would be very pleased, if a user could read my code and give me a answer/evaluation of my code! I don't find the mistake...

Re: My script crashes!
Mathias Mamsch - Tue Sep 15 08:51:42 EDT 2015

I already told you that the problem is here (according to the traceback), that DOORS is trying to access a property of a dialog box, that has already been closed. You need to get your dialog box closing straight. You have multiple sources that will close your dialog box 

1. The trigger (when the module is closed)

2. The user pressing close (X)

3. The "OK" function after you press Export

4. The current module when you close it (because your dialog will be parented to the current module, when you start it from there)

Especially problematic:

Inside the close, you delete the trigger, which means, closing the module from your loop fires the trigger, fires the closeDB, deletes the trigger while you are executing it?

So. Try to get this straight:

• Remove parenting of your dialog to the module by explicitly setting it to "dbExplorer" (see code comments below)
• Do not delete the trigger from the hideDB function. The trigger will be deleted, after the module has closed.
• Think about using "apply" rather than "OK" and manually close your dialog after everything finished from your callback.
• In the spirit of the "true source": call "hide excelBox" ONLY inside your closeDB function. In all other places call closeDB explicitly if you want to close your dialog.

Regards, Mathias

void makeBoxForModuleExport()
{
        // dont parent to module! parent to dbexplorer!
        // use: excelBox = create(dbExplorer, "String_Export_Excel", styleCentred )
        excelBox = centered LS_("String_Export_Excel", NLSTEMP_("Export Excel"))
    excelTrigger = trigger(module, close, 10, closeModuleTrig)  //"Schließen"-functionality of GUI
...
    ok(excelBox,LS_("String_Export", NLSTEMP_("Export")), doExcel)
    ...
    
    close(excelBox, true, closeDB)

    realize excelBox
}
    
    ...
    
    
bool closeModuleTrig(Trigger t)
{
    hide excelBox  // hide will call closeDB? 
    


void closeDB(DB db)
{
   delete args
    delete excelTrigger // delete the trigger, while we are executing? 
    
    hide excelBox
}
    


void makeBoxForFolderExport()
{
    // do not parent to current module, use excelBox = create(dbExplorer, "..", styleCentered)
        excelBox = centered LS_("String_Export_Excel", NLSTEMP_("Export Excel"))
        ...
        // use apply here? 
        ok(excelBox,LS_("String_Export", NLSTEMP_("Export")), doExcel)

        close(excelBox, true, closeDB)
}

Re: My script crashes!
Mathias Mamsch - Tue Sep 15 08:59:50 EDT 2015

Do you get the same traceback as before for the problem with the closeIfNonNull? If not then you might actually have two different problems ...

And please post the DXL error (including DXL traceback) you are getting if you have the chance ...

Regards, Mathias

Re: My script crashes!
AlexTidmarsh - Tue Sep 15 09:23:38 EDT 2015

Initial thoughts?

A variation in when the crash occurs given the same set of inputs would strongly hint at a memory leak problem.  The amount of memory that you start with will not necessarily always be the same.

A script that relies heavily upon global variables (e.g. the 'args' variable) , initialises them up-front, creates them near the end of the script and then never destroys them - well, that unfortunately is how a sizeable number of DXL (and BASIC) programmers write code - and it always makes me shiver.  It means they do not understand or care about memory leakage.  Nor about code maintainability.

This is the kind of script that I would in fact rewrite from scratch - making it look much more like a Pascal program and a lot less like a BASIC program - but that's what a 35-year career in general programming in many, many, different languages does to you .

To be brutally honest - my approach would be to study what the intent of the code is, and then rewrite it as a set of INDIVIDUALLY TESTABLE routines - i.e. routines that I can easily paste into the DXL Command window and test "in-harness" with a few input variables and a final print statement.

This implicitly means - avoid global variables - create and destroy them locally in the routine that uses them.  Try to only pass variables between routines as either function results or via the "pass-by-reference" or "pass-by-value" parameter mechanisms.  Once you know that each routine does "what it says on the tin", then you can build the functionality of the entire script warm and safe in that knowledge that each routine will not crap upon what the other routines are doing.   Furthermore, if objects are created and destroyed as far as possible within the confines of a single short routine that uses them, then memory leakage issues will be a lot easier to identify and solve.  This is a programming attitude that languages like DXL and BASIC do not encourage.  It is in fact the core principle behind languages like Pascal, Modula and Ada.  And it does pay off.   Trust me on this: I have had 35 years to understand this to be a given.  Just because you are using DXL or BASIC does not mean you cannot code as if you were a Pascal programmer at heart.

P.S.  Just read Mathias's post (injected as I wrote mine) - Begs the question of whether you have now moved from having an outright crash-dump to having a more coherent DXL error.  That would be progress at least. 

 P.P.S.  I would actually go as far as saying: only use a global variable if the language you are writing in gives you no other choice - which is in fact the main issue I have with DXL - some things can only be done using global variables.  But it does not mean you have to (or should) adopt this as a habit.  The age-old argument that using globals makes for faster code holds little water these days - computer hardware makes speed far less of an issue these days.  Programming, debugging and code-maintenance time is however as expensive as it has always been.

 

Re: My script crashes!
tobi_mehrl - Tue Sep 22 04:18:20 EDT 2015

Hi,

thanks to all which have answered my question. I have implemented the changes which have Mathias suggested. The problem is, that my script still makes a crash.

Furthermore I will show the DXL-interaction window output and the crash dump of Doors.

Crash dump:

DOORS: **** Translating a structured exception ****
DOORS: Version 9.5.1.2, build number 95088, built on Aug 13 2013 22:09:47.
DOORS: Microsoft Windows 7 Enterprise Edition Service Pack 1 (build 7601), 64-bit
DOORS: DOORS: 52 percent of memory is in use.
DOORS: There are 4194303 total Kbytes of physical memory.
DOORS: There are 3908628 free Kbytes of physical memory.
DOORS: There are 4194303 total Kbytes of paging file.
DOORS: There are 4194303 free Kbytes of paging file.
DOORS: There are 3fff80 total Kbytes of virtual memory.
DOORS: There are 399fd8 free Kbytes of virtual memory.

DOORS: argv[0]: C:\Program Files (x86)\IBM\Rational\DOORS\9.5\bin\doors.exe
DOORS: Exception timestamp: 22/09/2015 at 10:01:25
DOORS: doors.exe caused an EXCEPTION_ACCESS_VIOLATION in module doors.exe at 0023:007031BD
DOORS: 0023:007031BD (0xC17590FD 0x100127F7 0x100127EC 0x0C8ACDA4) doors.exe
DOORS: 0023:00686820 (0x76E2965E 0x00000000 0x005D63A6 0x0006084E) doors.exe
DOORS: 0023:76E26D51 (0x00000000 0x005D63A6 0x0006084E 0x00000437) USER32.dll, GetThreadDesktop()+0238 byte(s)
DOORS: 0023:76E2965E (0x0C8ACDF8 0x00000000 0x006874EB 0x0C8ACDF8) USER32.dll, GetWindow()+1008 byte(s)
DOORS: 0023:0068D44D (0x0C875848 0x0C96CFA0 0x0C9D2CF0 0x0C5A4C24) doors.exe
DOORS: 0023:00463C4A (0x0C5A4C24 0x07336120 0x6E2F2F20 0x00000000) doors.exe
DOORS: 0023:00662D48 (0x00000000 0x0C5A4C24 0x6E2F319E 0x00000001) doors.exe
DOORS: 0023:6E2F2F20 (0x00000001 0x00000000 0x00685EA3 0xC17592CD) MSVCP80.dll, std::basic_string<char,std::char_traits<char>,std::allocator<char> >::_Tidy()+0071 byte(s)
DOORS: 0023:6E2F319E (0xC17592CD 0x100127F7 0x100127EC 0x0C96CFA0) MSVCP80.dll, std::basic_string<char,std::char_traits<char>,std::allocator<char> >::~basic_string<char,std::char_traits<char>,std::allocator<char> >()+0009 byte(s)
DOORS: **** end of event ****
DOORS: Writing exception details...
DOORS: Exception details have been written to: C:\Users\amehto4\AppData\Local\Temp\DOORS-95088-2015_09_22-10_01_25-7060-1668.dmp
DOORS: **** Translating a structured exception ****
DOORS: Version 9.5.1.2, build number 95088, built on Aug 13 2013 22:09:47.
DOORS: Microsoft Windows 7 Enterprise Edition Service Pack 1 (build 7601), 64-bit
DOORS: DOORS: 52 percent of memory is in use.
DOORS: There are 4194303 total Kbytes of physical memory.
DOORS: There are 3889860 free Kbytes of physical memory.
DOORS: There are 4194303 total Kbytes of paging file.
DOORS: There are 4194303 free Kbytes of paging file.
DOORS: There are 3fff80 total Kbytes of virtual memory.
DOORS: There are 395318 free Kbytes of virtual memory.

DOORS: argv[0]: C:\Program Files (x86)\IBM\Rational\DOORS\9.5\bin\doors.exe
DOORS: Exception timestamp: 22/09/2015 at 10:12:49
DOORS: doors.exe caused an EXCEPTION_ACCESS_VIOLATION in module doors.exe at 0023:007031BD
DOORS: 0023:007031BD (0xC17590FD 0x100127F7 0x100127EC 0x0C8B22CC) doors.exe
DOORS: 0023:00686820 (0x76E2965E 0x00000000 0x005D63A6 0x0006084E) doors.exe
DOORS: 0023:76E26D51 (0x00000000 0x005D63A6 0x0006084E 0x00000437) USER32.dll, GetThreadDesktop()+0238 byte(s)
DOORS: 0023:76E2965E (0x0C8B2320 0x00000000 0x006874EB 0x0C8B2320) USER32.dll, GetWindow()+1008 byte(s)
DOORS: 0023:0068D44D (0x0C872830 0x0CA3C270 0x0CA82D18 0x07633114) doors.exe
DOORS: 0023:00463C4A (0x07633114 0x0BCB7D90 0x6E2F2F20 0x00000000) doors.exe
DOORS: 0023:00662D48 (0x00000000 0x07633114 0x6E2F319E 0x00000001) doors.exe
DOORS: 0023:6E2F2F20 (0x00000001 0x00000000 0x00685EA3 0xC17592CD) MSVCP80.dll, std::basic_string<char,std::char_traits<char>,std::allocator<char> >::_Tidy()+0071 byte(s)
DOORS: 0023:6E2F319E (0xC17592CD 0x100127F7 0x100127EC 0x0CA3C270) MSVCP80.dll, std::basic_string<char,std::char_traits<char>,std::allocator<char> >::~basic_string<char,std::char_traits<char>,std::allocator<char> >()+0009 byte(s)
DOORS: **** end of event ****
DOORS: Writing exception details...
DOORS: Exception details have been written to: C:\Users\amehto4\AppData\Local\Temp\DOORS-95088-2015_09_22-10_12_49-7060-1668.dmp

Interaction-Windows output:

-R-E- DXL: <utils/ole.inc:239> Es ist ein unerwarteter Fehler aufgetreten: doors.exe caused an EXCEPTION_ACCESS_VIOLATION in module doors.exe at 0023:007031BD

Rückverfolgung:
    <Line:504>
    <Line:960>
-R-F- DXL: <utils/ole.inc:239> Interner Fehler, senden Sie einen Fehlerbericht.
Rückverfolgung:
    <Line:504>
    <Line:960>

The ouput of the interaction-window points to line 960. In this line the script is in the "doExcel(DB)" routine at this line setCell(row, col, s, null, NO_HEADING). If you trace back to line 504, you will get the line "closeIfNonNull objCell". My guess is, that there is a problem with this ole object. In addition closeIfNonNull() is written as Wolfgang Uhr has described!

I have also attached the new version of my script.

Re: My script crashes!
Mathias Mamsch - Tue Sep 22 06:30:38 EDT 2015

This traceback tells a different story, than the DXL. Very curious. The traceback says: 

DOORS Main -- calls --> GetThreadDesktop -- calls ->  GetWindow () -- calls --> DOORS code --> Access Violation ... 

Looking at the description of GetWindow it says, that it will try to find a parent / child window and in its remarks we find the quote: 

An application that calls GetWindow to perform this task risks being caught in an infinite loop or referencing a handle to a window that has been destroyed. 

Also when looking at the traceback, you can see, that it is very very very short. This crash does not seem to be a normal DXL crash. Compare for example with the traceback you get executing code like that: 

int &ref = addr_ 0
ref = 4

If you would have the crash inside the interpreter loop of the DOORS client, then your Traceback should have many more entries. Therefore I think the DXL traceback is misleading here. 

Therefore it still leads me to the suggestion that something about dialogs isn't right yet. 

My next steps would be the following:

- Remove hiding of the dialog completely, i.e. 

    - remove the trigger from the code temporarily.  

    - replace the remaining "ok" calls with "apply"

    - remove the close callback

If that doesnt bring any meaningful difference, I would replace any "tempStringOf ..." by "stringOf" to avoid, that something tries to access an invalid Buffer memory. 

Only if this does not bring any difference, I would go in and comment out the content of the closeIfNonNull call ...

Maybe this helps, regards, Mathias

Re: My script crashes!
tobi_mehrl - Wed Sep 30 05:09:46 EDT 2015

Hi,

thank you for your answer. I have now find the failure in my script. I have changed the ok() function in the dialog box to apply() function in the dialog box. At this point, the script runs fine!

But, if i export a folder with e.g. 14 modules in it, the script is going very slow. A export process over 14 modules will take 3,5 hours! I know that this is a problem of the OLE automation.

Do you have any Idea to accelerate this export process?