Welcome to Telelogic Product Support
  Home Downloads Knowledgebase Case Tracking Licensing Help Telelogic Passport
Telelogic DOORS (steve huntington)
Decrease font size
Increase font size
Topic Title: DXL runs fine for developer but crashes for user
Topic Summary:
Created On: 6-Dec-2006 14:14
Status: Post and Reply
Linear : Threading : Single : Branch
Search Topic Search Topic
Topic Tools Topic Tools
Quick Reply Quick Reply
Subscribe to this topic Subscribe to this topic
E-mail this topic to someone. E-mail this topic
Bookmark this topic Bookmark this topic
View similar topics View similar topics
View topic in raw text format. Print this topic.
 6-Dec-2006 14:14
User is offline View Users Profile Print this message


Ross Blanton

Posts: 7
Joined: 15-Sep-2006

I developed a DXL program and tested it extensively myself, but when a user performs one of the use cases I tested, he gets the following DOORS errors:

In an errorbox: Unexpected internal error, suggest save, exit and restart"

In the DXL interaction window:  DXL inter-R-E- DXL: <config/menuFns.inc:366> An unexpected error has occurred: Unspecified Failure

Any ideas?  Do those errors give any clues as to what to look for?

Thanks,
Ross Blanton
Boeing

Report this to a Moderator Report this to a Moderator
 7-Dec-2006 01:45
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

I've given up sending exception violations or unexpected errors to Telelogic; they require a complete copy of all the data before they will even try to debug it.

If I got that I'd check if you get that error on HIS client; or him on yours. That should tell you if the bug is client dependant (probable cause clients have different DOORS versions), or DOORS user dependant.

If DOORS user dependant then you want to illiminate the possibility of a DOORS powers problem. From another Doors admin account login and change your powers from presumably DB Admin to the same powers as the user presumably Standard. Then login as yourself and see if you get the problem. If you do then your script is doing something that requires special powers.

If not then I'd suspect you have access to something he does not; most likely you can see a linked object but he cannot or perhaps you can see an attribute or object and he cannot. That's hard to track down.

Perhaps you want to post the part of the script giving the problem.

- Louie
Report this to a Moderator Report this to a Moderator
 7-Dec-2006 14:54
User is offline View Users Profile Print this message


Ross Blanton

Posts: 7
Joined: 15-Sep-2006

Louie,

Thanks for the good troubleshooting tips, those should help us narrow down the problem.

I would post the part of the script giving the problem, but I have no clues as to which part is guilty (the .inc file given in the DXL interaction window is not my file; I'm assuming it's one of Telelogic's files).

Report this to a Moderator Report this to a Moderator
 7-Dec-2006 21:18
User is offline View Users Profile Print this message


Marlin Wegner

Posts: 20
Joined: 2-Jun-2006

I have seen that error when I have walked off the end of a data structure. In other words overstepped the bounds of something like an arrya or skip list.
Report this to a Moderator Report this to a Moderator
 20-Dec-2006 16:01
User is offline View Users Profile Print this message


Pete Kowalski

Posts: 301
Joined: 7-Feb-2003

Ross,

Probably a stupid question but I ask anyways. Is the customer's error reproducible? Perhaps, in one of the user's steps lays the problem. Also, does the user and yourself have the same access rights in the same database?

Regards,

-------------------------
pete.kowalski(at)motorola.com
Report this to a Moderator Report this to a Moderator
 20-Dec-2006 18:41
User is offline View Users Profile Print this message


Ross Blanton

Posts: 7
Joined: 15-Sep-2006

Those are good questions.  Yes, the user's error is reproducible, but the manner in which DOORS crashes doesn't give us any clue as to what went wrong (at least I don't think it gives any clue, maybe I'm not looking in the right place.  I know some software creates a log file that can be helpful in diagnosing these type of problems, but I didn't think DOORS generates a log file.  Or, does it?).

The user actually has greater access priveleges in the database.  I know lesser could be a problem, but greater priveleges shouldn't cause a problem, should it?

Thanks,
Ross
Report this to a Moderator Report this to a Moderator
 21-Dec-2006 14:21
User is offline View Users Profile Print this message


Pete Kowalski

Posts: 301
Joined: 7-Feb-2003

It was never stated what DOORS version was being used here.

In DOORS 8.1, there are some useful functions to debug code such as dxlHere() In any regards, what I would do is insert print statements throughout the code to help isolate where the error is being introduced.

Are you and the client using the same database as well when the same code is executed? In the past, when I develop code I was using a test database. Unknown to me at times, people were making changes to the database that added unnecessary frustration to my development cycle.

Unfortunately, DOORS doesn't provide any nice features such as log files when DXL programs are executed. There are log capabilities that can be enabled on the server though. Lesson here is DOORS is a shrink wrap produce so if you want it you need to build it.

BTW, what exactly does this script do? Maybe if you can share some light we maybe able to help isolate where the error maybe such as common mistakes that people make.

-------------------------
pete.kowalski(at)motorola.com

Edited: 21-Dec-2006 at 14:23 by Pete Kowalski
Report this to a Moderator Report this to a Moderator
 21-Dec-2006 14:36
User is offline View Users Profile Print this message


David Pechacek

Posts: 674
Joined: 5-Dec-2006

I was getting those kind of crashes constantly when trying to retrieve the first value from an Array.  Was string data in the array index and tried to pull it out into a string.  Did:

string <variablename> = get(<arrayname>, <index1>, <index2> and got that crash every single time.

index1 and index2 were both 0.  index1 was a value passed in through the function call to where the statement was.  index2 was a loop index variable.

A guy at Telelogic actually got back to me offering help. Support couldn't help me since they limit help to 30 lines of custom DXL code.

-------------------------
David Pechacek
AAI Services Textron
dpechacek@sc-aaicorp.com
David.Pechacek@gmail.com
Report this to a Moderator Report this to a Moderator
 21-Dec-2006 14:55
User is offline View Users Profile Print this message


Ross Blanton

Posts: 7
Joined: 15-Sep-2006

We're using DOORS 7.1, but hopefully will be moving to 8.1 soon and will be able to try some of the new debug functions.

The problem does seem to be database-specific;  it seems to always run fine on a test database but not always in the live database.  The next thing I was going to look at was what database-specific properties could cause the problem, but since I wrote the posting higher priorities have come up and I've temporarily shelved debugging this program.

This is basically what the program does:

1.  Starts running when activated by a trigger that fires when a module is closed.
2.  Examines the history records of the objects in the module and determines if certain attributes have been changed or if objects have been created, deleted, or undeleted.
3.  If attribute changes meeting certain criteria have been made or if objects have been created, deleted, or undeleted, sends email notifications which vary depending on the nature of the changes to the module.

Thanks for all the ideas!  Even if I wouldn't figure this one out, this is great general info to help a DOORS/DXL rookie learn.



Report this to a Moderator Report this to a Moderator
 21-Dec-2006 15:04
User is offline View Users Profile Print this message


Ross Blanton

Posts: 7
Joined: 15-Sep-2006

Interesting.  My program is getting string values from an array.

Did you come up with a fix for your case?

What you were doing should have worked, right?
Report this to a Moderator Report this to a Moderator
 22-Dec-2006 00:41
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

Sounds like you need to determine if the error occurs before or after the Email notification is attempted. You could could output a message to a temp file something like this:
Stream s = append("c:/DebugMyTrigger.txt")
if (!null s)
{ s << "MyTrigger is about to try to Email: " today() "\n"
close(s)
}

At the end of the trigger you can erase the file:
Stream s = write("c:/DebugMyTrigger.txt")
if (!null s) close(s)


If its before (i.e. while parsing History): the hackles on the back of my neck are up. This feels a lot like its associated with Telelogic's hopeless effort to hide History from folks who didn't have access to the original item (that is, you can hide an object from someone but in v6 that someone could still review History to find its value). Even DB managers were getting lots of "read locked data" in History, and IIRC my History functions went berzerk until I surround each part with noError/lastError trapping.

If its after (i.e. while sending Email): Don't know, but you've got it narrowed down.

- Louie
Report this to a Moderator Report this to a Moderator
 20-Mar-2007 10:37
User is offline View Users Profile Print this message


Reik Schroeder

Posts: 361
Joined: 28-Jul-2003

Hi David,

this problem may be simply solved.
You need to cast the value as string even though you assign it to a string.
So your example would get:
string <variablename> = ( string get(<arrayname>, <index1>, <index2> ));


Greetings
Reik

-------------------------
Evosoft GmbH
for Siemens Industry Sector


Berlin, Germany
Report this to a Moderator Report this to a Moderator
Statistics
20925 users are registered to the Telelogic DOORS forum.
There are currently 1 users logged in.
The most users ever online was 15 on 15-Jan-2009 at 16:36.
There are currently 0 guests browsing this forum, which makes a total of 1 users using this forum.
You have posted 0 messages to this forum. 0 overall.

FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.