Zmann
Level: Master Delver

Rank Points: 241
Registered: 04-21-2003
IP: Logged

Um, when I try to export my player file, I just get a crash to desktop. That 'stderr' file stays on my desktop after the crash. The text file contains the following message:

Fatal signal: Segmentation Fault (SDL Parachute Deployed)

Don't know what's wrong, but it's annoying, because I need to get my player file on my other computer, but I can't export it.

mrimer
Level: Legendary Smitemaster

Rank Points: 5064
Registered: 02-04-2003
IP: Logged

Please post your three .dat files so we can try to reproduce the crash and perform a diagnostic of the situation. (This is with build 46/the release version, right?)

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.

Zmann
Level: Master Delver

Rank Points: 241
Registered: 04-21-2003
IP: Logged

File: Dat Files.zip (831.6 KB)
Downloaded 45 times.
License: Other
From: Unspecified

And here's your three dat files served on a hot platter. (And indeed, it was with build 46)

Zmann
Level: Master Delver

Rank Points: 241
Registered: 04-21-2003
IP: Logged

Must... export... player... file....

mrimer
Level: Legendary Smitemaster

Rank Points: 5064
Registered: 02-04-2003
IP: Logged

Sorry I haven't gotten to this yet. It'll be next on my list

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.

mrimer
Level: Legendary Smitemaster

Rank Points: 5064
Registered: 02-04-2003
IP: Logged

It's fixed and will be in a patch. In short, it resulted from not updating info when a sequence of room demos is recorded, and then demos are selectively deleted from the middle (or end) of the sequence. I've (1) made it so this doesn't happen in the future when demos are deleted, (2) put in a check for this situation so it doesn't crash on export, and (3) put in another check on export so that the incorrect data doesn't get exported either (and will quietly be fixed at that time).

Thanks for posting this so we could fix it -- relief is on the way!

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.

StuartK
Level: Smitemaster

Rank Points: 564
Registered: 06-10-2003
IP: Logged

mrimer wrote:
It's fixed and will be in a patch.

Heh. I would have encountered this bug a number of times, but I've not exported my player since build 34

Before you release the patch, did you see this one? I've now seen crashes (freezes) and black screens when changing resolution, colour depth, and refresh rate.

http://www.drod.net/forum/viewtopic.php?TopicID=1571&page=0


I've also had some problems importing holds and updating scroll messages successfully (I change the text, but the scroll goes blank) I suppose I ought to post seperately about it, but you seem to be keeping your eyes open... (hoping I didn't speak too soon )

mrimer
Level: Legendary Smitemaster

Rank Points: 5064
Registered: 02-04-2003
IP: Logged

StuartK wrote:
Heh. I would have encountered this bug a number of times, but I've not exported my player since build 34

Yeah, I thought of you when I worked on this one

Before you release the patch, did you see this one? I've now seen crashes (freezes) and black screens when changing resolution, colour depth, and refresh rate.

So far Erik's in charge of releasing the patches, so for good or for bad, probably nothing's gonna get released until he's back from hiatus. So we can work on this stuff in the meantime. Regarding this one, I'm not sure what to do about it. If a genius like Matt or a graphics-savvy guy like Gerry happen to know how to fix it, make sure they let me know!

I've also had some problems importing holds and updating scroll messages successfully (I change the text, but the scroll goes blank) I suppose I ought to post seperately about it, but you seem to be keeping your eyes open... (hoping I didn't speak too soon )

Feel free to send my way any holds you can't import and I'll check 'em out (keeping in mind if the hold was made before, oh, build 35 or so then there's a good chance it's just a corrupted hold because we were occasionally exporting out bad data back then). The scroll bug intrigues me, so if you can get a good set of steps together to reproduce it, do tell! Even if you see it only happening in a specific room of a specific hold of yours or something, that's fine. Just post the data files along with what you do to make the bug show up with them.

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.

trick
Level: Legendary Smitemaster
Rank Points: 2580
Registered: 04-12-2003
IP: Logged

mrimer wrote:

StuartK wrote:
Before you release the patch, did you see this one? I've now seen crashes (freezes) and black screens when changing resolution, colour depth, and refresh rate.

So far Erik's in charge of releasing the patches, so for good or for bad, probably nothing's gonna get released until he's back from hiatus. So we can work on this stuff in the meantime. Regarding this one, I'm not sure what to do about it. If a genius like Matt or a graphics-savvy guy like Gerry happen to know how to fix it, make sure they let me know!

It'd be nice with some more information. What OS is this on, does drod.err contain anything, and do other SDL games behave in the same way ?

I can't try this myself in Windows, but I did try it in Linux/XFree-4.3.0 by changing resolution and refresh rate (can't change bpp) while DROD was running in a window*, but I didn't get any crashes or black screens. So, either this problem is related to changing bpp (which could make sense), or it's Windows-specific (which could also make sense).

I have no idea how Windows handles these things, but a wild guess at what happens (don't treat this as fact!) is that when Windows change the screen attributes, it assigns a new screen surface to the DROD window, and also invalidates the old one. Now, when DROD resumes running after the change, it may still use the old screen, while the window is showing the new one. This could explain black screens and crashes. Another possibility is that DROD (via SDL) does in fact write to the new surface (which may just be the modified old one), but assuming that the bit depth is the same as before, so the data is all wrong and may end up outside the screen. This could explain garbage screens (possibly including black ones) and crashes.

In either case, this could happen while DROD is executing anything. The best way to fix it would be to use a event handler that gets called whenever this happens, no matter what DROD is doing at that moment, to fix the screen surface. The problem is that SDL events doesn't work that way. SDL just queue the events as they appear, for later handling. So, the right place to fix it would be in SDL, not DROD.

But, as I said, I have no idea what I'm talking about here. I hope it was entertaining, at least

*) For those interested, I used XRandR for the resolution/refresh change, not just virtual desktop change.

- Gerry

StuartK
Level: Smitemaster

Rank Points: 564
Registered: 06-10-2003
IP: Logged

mrimer wrote:
If a genius like Matt or a graphics-savvy guy like Gerry happen to know how to fix it, make sure they let me know!

In response to Gerrys questions, I've seen the problem in Windows XP and 98SE, graphics card is Nvidia Geforce3 Ti200 or an ATI antique. Points towards it being an SDL issue I guess, since there's nothing I can see in common between these two machines, except the OS is from the same source. I've not tried any other SDL games yet. I had a look at a couple but they were Mac or Linux only. Probably unlucky, I'll try later.

Feel free to send my way any holds you can't import and I'll check 'em out (keeping in mind if the hold was made before, oh, build 35 or so then there's a good chance it's just a corrupted hold because we were occasionally exporting out bad data back then). The scroll bug intrigues me, so if you can get a good set of steps together to reproduce it, do tell! Even if you see it only happening in a specific room of a specific hold of yours or something, that's fine. Just post the data files along with what you do to make the bug show up with them.

Firstly, my post was incredibly badly worded - I don't have any holds that are corrupt on importing. I just imported a hold (as opposed to create one entirely within the latest version of DROD) then had trouble with the message text when editing. I also cannot yet locate the original hold with which I had this problem (or else, it wasn't the hold that was the problem) I have multiple revisions of my hold, though I haven't been working on it recently (BTW, the other hold I sent you is included in this one, just incase you were wondering where it was It'll probably come out sometime before never)

FWIW, my current .player has been through something of the wringer (compared to my normal system of installing a new build, importing the same .player, and playing a few holds) I've been importing lots of holds (many oldies but goodies) keeping some, deleting others, editing others and generally abusing my DROD .dats. This may have caused a subtle problem, but if so, there aren't any other symptoms.

If it's just an issue importing holds from older builds, I don't see that there's much to worry about. And the problem appeared to be fixed by deleting the scroll and placing another one.

agaricus5
Level: Smitemaster
Rank Points: 1838
Registered: 02-04-2003
IP: Logged

StuartK wrote:
Firstly, my post was incredibly badly worded - I don't have any holds that are corrupt on importing. I just imported a hold (as opposed to create one entirely within the latest version of DROD) then had trouble with the message text when editing. I also cannot yet locate the original hold with which I had this problem (or else, it wasn't the hold that was the problem) I have multiple revisions of my hold, though I haven't been working on it recently (BTW, the other hold I sent you is included in this one, just incase you were wondering where it was It'll probably come out sometime before never)

FWIW, my current .player has been through something of the wringer (compared to my normal system of installing a new build, importing the same .player, and playing a few holds) I've been importing lots of holds (many oldies but goodies) keeping some, deleting others, editing others and generally abusing my DROD .dats. This may have caused a subtle problem, but if so, there aren't any other symptoms.

If it's just an issue importing holds from older builds, I don't see that there's much to worry about. And the problem appeared to be fixed by deleting the scroll and placing another one.

I had the problem too - I think it was somewhere between Builds 26 and 36 there were some nasty text-losing bugs in the program. If you are importing a hold created at that time and affected by the bug, then there will still be no text in the scrolls because it wasn't copied over into the hold file. Re-writing the scrolls if it is your hold will solve the problem.

____________________________
Resident Medic/Mycologist