[Bricksmith] MPD file handling crash


[Bricksmith] MPD file handling crash
#1
I've just accidentally discovered that a circular reference in an MPD file with cause Bricksmith to crash. I know it's invalid syntax and I'm not sure how hard it is to detect but it certainly crashes the programs.

Also, how do I add a reference to a part that not in the parts list and not in the MPD itself? I thought I've done this before but for some reason I figure out how to do it.
Reply
Re: [Bricksmith] MPD file handling crash
#2
Orion Pobursky Wrote:
-------------------------------------------------------
> I've just accidentally discovered that a circular
> reference in an MPD file with cause Bricksmith to
> crash. I know it's invalid syntax and I'm not
> sure how hard it is to detect but it certainly
> crashes the programs.

That's no great shock. But thanks for the report; I'll see what I can do.

> Also, how do I add a reference to a part that not
> in the parts list and not in the MPD itself?

1. Add a random new part. It doesn't matter what it is.
2. Open the Inspector pane.
3. Manually type in the name of the file you want to reference. Hit return.

Allen
Reply
Re: [Bricksmith] MPD file handling crash
#3
Orion Pobursky Wrote:
-------------------------------------------------------
> I've just accidentally discovered that a circular
> reference in an MPD file with cause Bricksmith to
> crash. I know it's invalid syntax and I'm not
> sure how hard it is to detect but it certainly
> crashes the programs.

I can prevent the creation of circular references. Detecting them in existing files is more complicated. Did you run into this problem with a file created outside of Bricksmith, or did you accidentally create one inside Bricksmith?

Allen
Reply
Re: [Bricksmith] MPD file handling crash
#4
Just as a note, in LDView, I use an STL std::map object of strings to bools to track the whole list of parent, grandparent, etc. models while loading. There is the single map for the top-level file that the user loaded. When I enter my submodel loading code, I check to see if the value in that map for the current filename is true. (If there is no value in the map, one is automatically added with a value of false.) If it is true, I bail with "model loop" error. If it isn't, I set it to true, then load the model along with all its sub-models. After loading the model and its submodels, I set the value back to false. The same could be done with an NSDictionary of NSNumbers.
Reply
Re: [Bricksmith] MPD file handling crash
#5
Travis Cobbs Wrote:
-------------------------------------------------------
> Just as a note, in LDView, I use an STL std::map
> object of strings to bools to track the whole list
> of parent, grandparent, etc. models while loading.

Just curious, did you implement this because you encountered files in the wild which contained circular references, or were you just coding defensively? As you might gather from the title of this thread, the current version of Bricksmith crashes the instant you attempt to create a circular reference, so it certainly isn't possible to save such a thing from it.

Allen
Reply
Re: [Bricksmith] MPD file handling crash
#6
Someone reported a crash, and after investigation it was determined that his development parts had one file as a moved-to that referred to another file that was in turn a reference to the moved-to part. So I added the code as a direct result of a crash in the field. The currently released LDView has a bug in its detection of circular references such that if one of the sub-files of an MPD refers back to the main subfile of the MPD, it still crashes. I've fixed that in my development code tree, but the reason I found out about the problem is that a different user reported that crash.
Reply
Re: [Bricksmith] MPD file handling crash
#7
I did fail to put things into context in my previous post. The original LDView release (version 0.1) was in June of 2000. The first time anyone reported the circular reference crash to me was in July of 2007. The only other circular reference crash that has been reported to me (the MPD one) was reported in February of this year. So it does appear to be rare. The problem with the part example, though, is that if anyone has such a broken part, anything that causes your program to try to load that part (such as merely clicking on it in the parts list) will cause a crash.
Reply
« Next Oldest | Next Newest »



Forum Jump:


Users browsing this thread: 2 Guest(s)