Jump to content
The Dark Mod Forums

Recommended Posts

Damn, the XdFilechooser makes problems again on win32 release build on my side (didn't test x64), when I don't launch it through the IDE. It crashes on the initial load when the definition is duplicated and it crashes, when importing a duplicated definition regularly via the GuiSelector and the pagecounts of the XData definitions don't match up. Since its hard to do this without a debugger and since it all works perfectly when launched through the IDE, I guess I'll just disable previewing for XdFileChooser for this release. It's rather rare that you run over a duplicated definition anyway.

 

I uploaded the files in case you still want to take a look. The problematic definitions are "testing/test" and "readables/source_material/tdm_universe_city_book". You would just have to uncomment one line in onSelectionChanged() if you want to test it.

bla.xd.txt

readableeditortestbla.xd.txt

unnamed2.xd.txt

Link to post
Share on other sites
  • Replies 234
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

I was able to attach the debugger and catch an access violation in the ~RenderableCharacterBatch() destructor. The call stack is mostly useless, but the crash seems to be coming from my nvidia driver, in the call to glDeleteBuffersARB.

 

It's well possible that this is an openGL-related issue, probably due to some mistake on my behalf. I'll be off to bed today, maybe there's a chance that I look into it tomorrow or during the weekend.

Link to post
Share on other sites

Hm, no. This is not the right tree I'm barking up.

 

The first google search results in this link: http://stackoverflow.com/questions/2347562/program-crashes-only-in-release-mode-outside-debugger

 

It suggests that there is some memory leak/overwrite/corruption going on somewhere. This fits in the picture we're getting, as the behaviour is rather inconsistent.

Link to post
Share on other sites

Ah ok. Well I guess we should postpone the release then for now. If it's really a leak, commenting previewing out in a class probably is not really a fix.

 

I'll have to check my code and see what could possibly leak. Seeing that I used shared_ptr nearly everywhere, one would think a leak would be easy to find.

 

Edit: Uhm, yeah! Little embarrassing!! :D Forgot to clear the vectors in the destructor of the XData class... I think that fixed it. At the time I started coding I wasn't familiar with the STL yet, so I didn't realize std::vector is a dynamic structure that need to be freed. Sorry! :)

Link to post
Share on other sites

The std::vector class is clearing itself upon destruction, or were you allocating them on the heap, using new std::vector()?

 

edit: the crash is still there.

 

edit2: It's reproducible: create a readable, open dialog, open xdataselector, choose readables/source_material/tdm_universe_city_book, OK, select the third option unnamed2.xd, hangup.

 

This is my xdata folder: http://www.dramthethief.com/darkmod/files/xdata.7z

Link to post
Share on other sites

Nope, I never used regular pointers. I only use the new pointer on the shared_ptr constructor...

 

Same goes for std::map I assume?

 

@edit2: Yeah, that seems to be that issue with the amount of pages again. The first two readables have 3 pages and the third has 4. Deleting the two page4 statements fixes it, although num_pages still says 4 and there's also a forth gui defined.

 

Edit: I attached DarkRadiant.exe to the debugger and there's a runtime_error exception on the DefTokeniser in the hasMoreTokens() method. The tokeniser object itself cannot be evaluated. Seems like that one doesn't exist anymore for some strange reason. I am not very familiar with this kind of debugging though. I am doing this on the release build, maybe that has something to do with it? The weird thing is that when I continue execution, everything imports fine and the preview works as well.

Link to post
Share on other sites

Same goes for std::map I assume?

Yes. All objects in an STL container will get their destructor called when the container itself is cleared or destroyed.

 

@edit2: Yeah, that seems to be that issue with the amount of pages again. The first two readables have 3 pages and the third has 4. Deleting the two page4 statements fixes it, although num_pages still says 4 and there's also a forth gui defined.

I take it, the amount of pages makes it crash in release builds only? That'd be strange.

 

Edit: I attached DarkRadiant.exe to the debugger and there's a runtime_error exception on the DefTokeniser in the hasMoreTokens() method. The tokeniser object itself cannot be evaluated. Seems like that one doesn't exist anymore for some strange reason. I am not very familiar with this kind of debugging though. I am doing this on the release build, maybe that has something to do with it? The weird thing is that when I continue execution, everything imports fine and the preview works as well.

Debugging a release build has some glitches, as many objects present in the code (like temporaries) can be optimised away in the actual release build, so it might appear that the instruction pointer is skipping lines. Also, you cannot always inspect the classes in the memory.

 

Make sure the crash is reproducible and it happens always in the same place, even if you do something different before the actual reproduction steps. If the crash is not occurring in the same location every time and seems to randomly depend on the action you do before reproducing the crash, there is definitely some heap corruption going on.

 

If all else fails, there's "cave-man debugging", which means that you speckle your code with std::cout output (disabling the StdCOutRedirector in the main radiant binary) and check where the crash is happening. This is how I debugged the first year in my DarkRadiant development, because I didn't have a working debugger back then. What a pain, but you learn a lot of things about the code and you know class names by heart afterwards.

Link to post
Share on other sites

Ok, I think I got it. Stupid again, actually! Forgot to initialize _numPages on XData objects. Well, I intended too, but I used the wrong method. So what happens is that the last value was used (3 in this case) and the setContent resulted in the runtime_error then because the acquired pageIndex exceeded numPages.

 

Yup, that fixed it! FINALLY!! I'll compile the release builds now then after some further testing and upload to sourceforge, okay?

Link to post
Share on other sites
Yup, that fixed it! FINALLY!! I'll compile the release builds now then after some further testing and upload to sourceforge, okay?

Wait a sec, don't be so quick on the draw. I'd like to do some rudimentary checking on my own before we go ahead and upload it. On top of that, I also need a chance to update the darkradiant website, and I'm in the office currently where I can't do that.

 

Glad you found the issue though, finally that one is fixed.

Link to post
Share on other sites

Ok, sure! I tend to get a little over-exited, sorry. Especially regarding Springs announcement. Would be a shame to waste the opportunity, when we're basically set! I'll give him a hint about our status. Maybe he decides to wait a little, if not, fine as well!

 

I'll get the packages ready for release and when you give the "ok", I can directly upload them, unless you want to do it yourself.

Link to post
Share on other sites

I wouldn't be too concerned about a simultaneous announcement. There's definitely an argument that two separate announcements are better than one! :)

 

(This, by the way, is exactly the same reason why game developers like to tease about their games slowly - release little bits of information regularly, you ultimately wind up with more attention that way.)

My games | Public Service Announcement: TDM is not set in the Thief universe. The city in which it takes place is not the City from Thief. The player character is not called Garrett. Any person who contradicts these facts will be subjected to disapproving stares.
Link to post
Share on other sites

I just doublechecked our dependencies. There were actually some missing. I wasn't quite sure how to add the MODULE_ARCHIVE dependency. I appended "PK4" for now. Module names are also missing for idialogmanager.h, itextstream.h and irenderable.h. I assume those don't need to be added to the dependencies?

Link to post
Share on other sites

I'll go through them. You won't need the ArchivePK4 dependency, as this is implicitly handled by the VFS. You don't access PK4/ZIP files directly, do you?

Link to post
Share on other sites

Ok, done, not a big deal.

 

I briefly tested the 32 bit version, I think we're ok. Do you know exactly which files to create and where to upload them? We need both 32 bit and 64 bit installers as well as ZIPs. You can use the DarkRadiant_install folders to create the ZIPs.

Link to post
Share on other sites

Yup, got it already. Uploading right now! Although the information on sourceforge seems to be outdated. I am currently uploading to /home/pfs/project/d/da/darkradiant/darkradiant/1.2.0 . Clicking on frs changed my directory to that folder. Tried it multiple times. I guess they've renewed that system.

Link to post
Share on other sites

Tried it multiple times. I guess they've renewed that system.

Yes, the release system has been changed every of the last three times I prepared a release. Those guys seem to make a sport out of it. For me that's just tiresome to figure out where to put the fricking files everytime again.

Link to post
Share on other sites

Yeah, added that. Though people will notice soon enough.

 

Next up will be some planning towards 1.3.0, I'm going to push a few issues on the roadmap. The transparency rendering issue or the I18N project sound like suitable near-term goals.

 

What are you going to tackle next? Refactoring the XData class structure?

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...