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: Baseline sets in DXL
Topic Summary:
Created On: 20-Jul-2006 21:36
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.
Answer This question was answered by Chris Jones, on Friday, August 11, 2006 10:42 PM

Answer:
I think I've finally fixed the thing!

At some point I decided to make a big test setup (including a fake "system spec" with lots of links to other modules) so that I could reproduce the problem my other users were having on their (live) modules. I also went through the "manual" baseline set process and to try and figure out any differences. After a lot of troubleshooting, I realized that the built-in baseline set creation process closes all the modules you're adding to the set before it baselines them. Tried doing so in my script, and no more problems!

Moral of the (very long [for me at least]) story: If you're making a baseline set in DXL, please, for the sake of your sanity, CLOSE everything before you get too far. I have no idea why this makes such a difference, but it does.

Chris
 20-Jul-2006 21:36
User is offline View Users Profile Print this message


Chris Jones

Posts: 177
Joined: 1-Jul-2005

Does anybody have good info on making a baseline set in code?

We have a script that follows links and makes a baseline set (and definition) and I was not really clear on the right procedure when I wrote it. It worked for a while but I added a recursive element for the links and rearranged the program, and now it's crashing frequently and not giving very useful errors. Like, one was an EXCEPTION_ACCESS_VIOLATION, and the line it pointed to was a Skip list creation about 8 lines in, which was "backtraced" to a comment line.....and it did this after almost all the script had run and had baselined everything but the original module.

I'm totally lost. The other thing is that it doesn't seem to crash in quite the same way every time. Any help would really be appreciated.

Chris
Report this to a Moderator Report this to a Moderator
 20-Jul-2006 22:07
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

First check would be to verify your Recusion is sound: the recursive function must return without recursing when you get to the end of the links. I'd be tempted to have a global skip list that houses the links you have already traversed; the function checks the skip and if the link is there then it doesn't recurse anymore.

2nd check would be to make sure your links do not circle, such as object A links to B links to C links to A.

3rd check would be to make sure you are not running out of stack. Near the top of your DXL you can set timeout to never and stack to a big number as follows:
pragma runLim, 0
pragma stack, 50000

Another check may be in your call parameters. If a function modifies a typical call parameter variable, the function should specify its name with the ampersand: void Increment(int &i) { i++}. I don't recall the rules, but the complicated variables cannot be ampersanded (such as Buffer parameters).

I have seen at times the DXL errors have the correct line number but specify the wrong file. Thus if it says you've got an error in line 20 of file ABC.dxl, its remotely possible that the real error is in line 20 of some other file, probably an encrypted DXL of Telelogic's.

- Louie
Report this to a Moderator Report this to a Moderator
 21-Jul-2006 01:12
User is offline View Users Profile Print this message


Chris Jones

Posts: 177
Joined: 1-Jul-2005

Good points....thank you, Louie. The recursion stops whenever it finds a non-empty object, but the nested if statements got kind of complicated so I'm not sure it did or not. Fixed that.
I am using a skip for the modules I've already decided to use, but not for every one that it's already seen, since Module A could link to a zillion different objects in B, each of which could link to a separate module C, D, E, .... There could be something else in there that needs a closer look.

I've added a bunch of logging to the script so I can see exactly where it fails. (I might do startDXLTracing_ also but that's kind of a last resort.) The hard part is getting hooked up with one of the (very few) users who actually use this script (since it naturally doesn't fail for me ).

Thanks again. I'll see what I can find out....

Chris
Report this to a Moderator Report this to a Moderator
 21-Jul-2006 15:59
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

If it works for you but not for someone else, I'd suspect an access rights problem. DXL is kind of sloppy and it wouldn't surprise me to find that you can get a handle on something (perhaps an 'Object') yet not have any 'R' access to it. There are numerous calls that trigger rude abort DXL messsages unless the input parameter is valid, you thus need lots of statements like "if (null obj) log error and continue".

In this case I'm pretty sure you can see an outgoing link but not be able to see the target object.

I'll look over the code if you like.

- Louie
Report this to a Moderator Report this to a Moderator
 25-Jul-2006 01:26
User is offline View Users Profile Print this message


Chris Jones

Posts: 177
Joined: 1-Jul-2005

I hadn't thought of that case......but I *had* for some reason put in checks for isDeleted and null objects. I tried things without them and got some errors but not like we've been getting. Also, in general I have less access than the users who actually make use of this script, and I am almost positive there's nothing that people don't have read access to, so that "shouldn't be" a problem.

Another mystery is that it usually asks, "Modified modules must be saved before they can be baselined. Do you want to save modified modules now?" even when everything was already saved, even if I just barely baselined it nine seconds ago. Having other modules in the set open does not seems to affect anything either. As far as my code goes, this happens while the addBaselines() line is going. Trying to figure out why it's doing this....

I may take you up on that offer to look it over. My most-frequent user for this script is out all week so I might have to wait until next week to see if it is still dying (it seems to have worked fine once on Friday).

Chris
Report this to a Moderator Report this to a Moderator
 11-Aug-2006 22:42
User is offline View Users Profile Print this message


Chris Jones

Posts: 177
Joined: 1-Jul-2005

Answer Answer
I think I've finally fixed the thing!

At some point I decided to make a big test setup (including a fake "system spec" with lots of links to other modules) so that I could reproduce the problem my other users were having on their (live) modules. I also went through the "manual" baseline set process and to try and figure out any differences. After a lot of troubleshooting, I realized that the built-in baseline set creation process closes all the modules you're adding to the set before it baselines them. Tried doing so in my script, and no more problems!

Moral of the (very long [for me at least]) story: If you're making a baseline set in DXL, please, for the sake of your sanity, CLOSE everything before you get too far. I have no idea why this makes such a difference, but it does.

Chris
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.