Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Dareon Clearwater]

This is, unfortunately, going to be a very vague bug report.  I have several mason's workshops, all set to Construct Rock Blocks/R.  My general plan is to let the dorfs use whichever one they like until it's CLT or worse, then switch off the job and use the blocks.  Since the shops are built on the sites of mining, it's hard to check them all in one pass, so I've been using the unit menu and zooming to the buildings the masons are working in.

Twice now it's frozen and crashed on me after a few incidences of working normally.  I have no idea whether it's a specific workshop causing it, since the crash occurs immediately after hitting b, and doesn't even get out of the unit menu.

[Magua]

I may not be more useful:

I'm building a pump tower -- first the floors, then the pumps, then I wall things in.  It's a little cluttered, and there's a lot of dwarves doing work. 

I'll occasionally get the "Construct building cancelled: Item is in the way" message followed by "Dwarves have suspended construction of Wall".  I go to the 'j'ob menu, find the suspended job, and then go to 'b'uilding to unsuspend it. 

Most of the time this works fine, but twice now it has crashed with a memory exception, trying to read 0x00000000.  It's not reproducible -- I'll reload and do the exact same actions again, and the problem does not occur.

[Deathworks]

Hi!

I may be wrong, but this sounds a lot like reported bug 1005:

# 001005 □ [dwarf mode][interface][unit-job screen]    it crashes occasionally when zooming to a building from the unit/job view

Unfortunately, I am afraid that will not help you very much (^_^;;
However, I think I saw a thread about this bug recently here in the bugs forum (this is why I knew the bug existed), so maybe people know some workaround or have more advice...

Deathworks

[Draco18s]

However, I think I saw a thread about this bug recently here in the bugs forum (this is why I knew the bug existed)

You're looking at it.
Well, there's another thread, but since a previous poster had the problem again, he posted noting that it is a [Hard to Reproduce] bug.

[Deathworks]

Hi!

I am a bit confused there, Draco18s. The posters in this thread here are Dareon Clearwater and Magua, while the posters in the other thread (39f Zoom to suspended building causes crash) were Daemon_TW, Beredix, The Dark Bunny, Ryo, Starver, Kurtm, and Techhead.

So, unless Dareon Clearwater or Magua are using multiple accounts, neither of them is a "previous poster" from that thread.

Unfortunately, the other thread does not really seem to yield any help for avoiding it and only presents us with a puzzled Toady One... (T_T)

Deathworks

[Draco18s]

So, unless Dareon Clearwater or Magua are using multiple accounts, neither of them is a "previous poster" from that thread.

My mistake.  I was taking a stab at it.  Likely one of them saw that thread though.

Unfortunately, the other thread does not really seem to yield any help for avoiding it and only presents us with a puzzled Toady One... (T_T)

Quite.

[Toady One]

If the save is particularly prone to this problem, I'd like to take a look at it.  I don't have very much to work with at this point.  I'll need the region folder in some kind of zip/rar/7z, and any new objects that were added to the raw folder.  If it's less than 20 megs, you can send it to toadyone@bay12games.com.  You can also try The Dwarf Fortress File Depot which has a special section for bugged saves.

[Keldor]

Hmm.  A memory error at 0x00000000 almost certainly means that you're trying to access an uninitialized pointer.  It there a conditional somewhere in adding buildings to the building list which ends up inadvertantly skipping the pointer assignment?  The fact that it doesn't crash the moment you bring up the building list indicates that the pointer to the room, at least so far as name/description is valid, so the culprit has to be a pointer accessed only when the zoom to function is invoked.

That the pointer is still null implies that it was never set in the first place, as opposed to an error in some update, so the cause happened before the building was ever suspended.

What specific types of buildings have had this problem?

[Derakon]

The usual behavior I get from uninitialized pointers is garbage data, not 0, though I grant this is compiler-specific. I'm just pointing out that it's also possible that Toady's setting something to 0/null and then accessing it, which would happen, say, if you ran off the end of a linked list (where you use a null child pointer to indicate the end), for example.

[Sukasa]

Usually, whatever garbage the pointer will have is whatever was physically present in the bytes of RAM that the Pointer is stored in - no init means that these garbage bytes from an earlier program running are now brought into DF via the bad pointer.

[Zulaf]

Ive had this crash happen to me for about the last 3 games, but the first 2 where not reproducible accuratly enough so i kept starting again. i got one now that is accurate and reproducible. the crash happens when i go to see what one my my miners are building. it takes a few tries to happen. this also may not matter but i would press f1 to go to the main door before i would look at what was being built which was one level up from the main door.

Here is the file on DFFD:  http://dffd.wimbli.com/file.php?id=609


EDIT: sorry i forgot to mention afew tidbits.
First this is a fresh world, i do not use worlds or saves or anything from previous versions.
Second i downloaded the small version if that has anything to do with anything.

BLEH EDIT 2: also forgot to say no mods no cheats just plain old vanilla df

[Toady One]

Thanks, I'll give it a try at some point, most likely prior to the next release for this bug.