0000706: Trying to access the squad screen mid-combat caused a complete game hang

(0001717)
oliver (reporter)
2010-04-07 04:35

I was going to attach a screenshot, but I can't find the interface to attach files to an issue!

(0001718)
Footkerchief (manager)
2010-04-07 04:36

A screenshot doesn't matter as much as reproducibility. It would be helpful if you determined whether this can be reproduced, and how.

(0001719)
oliver (reporter)
2010-04-07 04:40

I also preserved the dump generated when I terminated the process (hdmp/mdmp files) if that's useful - I'm not familiar with debugging under Windows - but they are ~300MB in total so I will need to arrange to transfer them directly to someone who can use them.

(0001721)
Footkerchief (manager)
2010-04-07 04:47

A full memory dump is overkill -- all that's really needed is the Dr Watson log file or user.dmp file -- but you could upload the dump here http://www.zshare.net/ [^]

(0001723)
oliver (reporter)
2010-04-07 05:03

Ok - as I said I know nothing about the mechanics of debugging under windows - so what exactly do I need to send?

I have (stolen from the info in the "do you want to tell microsoft all your secrets" process-termination dialog):

dwarfort.exe.mdmp - 13MB
dwarfort.exe.hdmp - 291MB
appcompat.txt & manifest.txt which just look like metadata.

Which of these are needed, or is there another dump I should be looking for?

(0001725)
Footkerchief (manager)
2010-04-07 05:24

Uploading the mdmp file should be enough.

(0001909)
Nighteyes (reporter)
2010-04-07 18:55

I think that you have found the cause of the crash that I posted (0000243)
Sounds like the same symptoms, but you got far more detail then I found.
I found that if I loaded the save the same thing would happen. I may still have the save but I'd have to go hunting.

(0002307)
Rafal99 (reporter)
2010-04-09 05:21

Also related to: 0000869

(0006234)
foxbyte (reporter)
2010-05-05 20:44

I just got something similar to this. After a fight with a titan I tried to cancel the orders of my squads [I had to use Move to fight the thing, since if I ordered them to Kill it they would all run back down to the barracks and re-arrange their equipment] but instead of assigning the orders to the entire group it kept forcing me to give orders to individuals.

Then when I used /*-+ to go through the menu, the program froze up solid. There's no amount of magma that can unfreeze DF. :(

(0008205)
DanielP (reporter)
2010-06-12 12:13
edited on: 2010-06-12 12:35

I had the same issue today in 0.31.06, after I tried to give a dwarf a separate move order.

http://www.bay12games.com/dwarves/mantisbt/view.php?id=2254 [^] is probably also the same issue.

(0008500)
oliver (reporter)
2010-06-15 06:59
edited on: 2010-06-15 07:01

I saw this again today under .06, using the Linux version.
Unfortunately I didn't think to grab a coredump when it hung.
Next time I'll try to do that. It's not frequent, I've only seen it twice.

Possibly the trigger is related to giving individual orders to members of a squad - I don't commonly do that, but I was using individual orders just before both crashes.

(0008529)
Terisuke (reporter)
2010-06-15 14:30
edited on: 2010-06-15 14:31

I have been able to reproduce this crash by accessing the squads screen after assigning individual station orders. I saved right before the squad assignment, so I tried to do it again, again getting the crash.

My actions each time were:

Assign Stations to one member from each of two squads
Combat ensues
View reports, then return to main screen.
Attempt to pull up squad interface - causes crash.

EDIT: 0.31.06, Mac OSX

(0008534)
Footkerchief (manager)
2010-06-15 15:32

Do those actions reliably produce a crash on ANY save? If not, it would be helpful for you to upload your save to http://dffd.wimbli.com/ [^]

(0008563)
DanielP (reporter)
2010-06-16 12:06

At least for my current fortress I could reproduce it for different years and with different squads, but apparently the squad has to be active before assigning the individual station orders. It also happened with a squad, which had only one member.

(0008740)
vwspeedracer (reporter)
2010-06-19 20:27

Just experienced this in 31.08 when sending an individual bowman to kill a goat. (He was pretty unhappy so I figured some blood and guts would cheer him up.) Unfortunately it's been nearly a season since my last save, so I don't have a useful file. Win7x64, taskman showing nonresponsive with 100% usage of the core it's running on, so some sort of loop or runaway?

(0009040)
bronwen (reporter)
2010-06-23 21:36

I experienced this in 31.08 when trying to cancel the kill order for a giant mole. I had 2 squads, had successfully cancelled one squad's orders, found the dead mole and confirmed it was dead then attempted the cancel the other squad's orders. I believe I hit the wrong key a few times and then when I hit the right key, DF hung. However earlier in the game I had no problems using the squad menu in pretty much exactly the same way (only it was for alligators).

(0009047)
greycat (reporter)
2010-06-24 07:38
edited on: 2010-06-24 09:03

I just got this too. 31.08 under Linux (Debian 5.0). I had one dwarf actively fighting against an unkillable forgotten beast (made of salt - I'd chopped all four of its feet off, but several months of chopping at it everywhere, including several instances of twisting an embedded steel axe in its head, weren't doing any additional damage). I had just sent another dwarf (part of a squad, but sent individually) to get some weapon and armor practice as well. I pressed 's' again, and I think that's when the entire process hung.

Other things that were occurring at the same time included one dwarf making an artifact (in a craftdwarf's shop), and some elves hanging out at the depot, having just been traded with. Plus assorted dwarvery.

Attaching with gdb gives this:

(gdb) bt
#0 0xb80ae424 in __kernel_vsyscall ()
#1 0xb79313b5 in sem_wait@@GLIBC_2.1 () from /lib/i686/cmov/libpthread.so.0
#2 0xb804dd98 in SDL_SemWait () from /usr/lib/libSDL-1.2.so.0
#3 0xb7bf7c96 in enablerst::async_wait ()
   from /home/wooledg/df_linux/libs/libgraphics.so
#4 0xb7bf8117 in enablerst::do_frame ()
   from /home/wooledg/df_linux/libs/libgraphics.so
#5 0xb7bf8379 in enablerst::eventLoop_SDL ()
   from /home/wooledg/df_linux/libs/libgraphics.so
#6 0xb7bf9015 in enablerst::loop ()
   from /home/wooledg/df_linux/libs/libgraphics.so
#7 0xb7bf9862 in main () from /home/wooledg/df_linux/libs/libgraphics.so
#8 0xb7954455 in __libc_start_main () from /lib/i686/cmov/libc.so.6
#9 0x0804d011 in ?? ()

I don't know how helpful that is. The process is eating CPU. Reproduceability is nil. :(

(0009884)
skeeve (reporter)
2010-07-10 09:20

df 31.08, win7 64bit
Just seen the same thing.
It seems i can reproduce this so :
assign a kill order to squad/individual -> unpause -> wait til the attacked creature has left the map -> press "s" for squad screen. -> hang.

I 'm not entirely sure, but i get "same hanging" with appointed military captains assinged to squads. Then remove captain from noble screen. Then pressing "m" for military screen it hangs.

(0009891)
oliver (reporter)
2010-07-10 15:32

@greycat: FWIW, under SDL versions, you actually want a stacktrace from a different thread, not the main thread. The main thread is just doing rendering; the simulation (which has hung) runs in a separate thread. The stacktrace above just shows the rendering thread is waiting for the simulation thread to complete simulation of the next frame. Try "thread apply all bt" under gdb.

(0010060)
Footkerchief (manager)
2010-07-12 12:49

From 0002660:

Save: http://dffd.wimbli.com/file.php?id=2668 [^]
I use mayday graph. pack.

1) Press "s" and command them to go somewhere
2) Wait for 4-5 minutes
3) Try to hit "s" again. Sometimes it crashes, sometimes it doesn't

(0010122)
Toady One (administrator)
2010-07-13 05:40

This one has been fixed for 0.31.11. Until then, when you give individual orders to squads, it'll be safest if you unselect any individuals before leaving the squad menu. The crash can come when it tries to make your old selection persist and a loop is indexed wrong.

Issue History
Date Modified	Username	Field	Change
2010-04-07 04:34	oliver	New Issue
2010-04-07 04:35	oliver	Note Added: 0001717
2010-04-07 04:36	Footkerchief	Note Added: 0001718
2010-04-07 04:40	oliver	Note Added: 0001719
2010-04-07 04:47	Footkerchief	Note Added: 0001721
2010-04-07 05:03	oliver	Note Added: 0001723
2010-04-07 05:24	Footkerchief	Note Added: 0001725
2010-04-07 18:55	Nighteyes	Note Added: 0001909
2010-04-08 02:18	Nighteyes	Tag Attached: combat
2010-04-08 02:18	Nighteyes	Tag Attached: squad
2010-04-09 05:19	Rafal99	Tag Attached: Squad menu
2010-04-09 05:21	Rafal99	Note Added: 0002307
2010-04-09 09:18	Footkerchief	Relationship added	related to 0000869
2010-04-09 09:47	Footkerchief	Relationship replaced	parent of 0000869
2010-04-09 09:47	Footkerchief	Relationship added	parent of 0000243
2010-05-05 20:44	foxbyte	Note Added: 0006234
2010-06-12 12:13	DanielP	Note Added: 0008205
2010-06-12 12:27	DanielP	Note Edited: 0008205	View Revisions
2010-06-12 12:34	DanielP	Note Edited: 0008205	View Revisions
2010-06-12 12:35	DanielP	Note Edited: 0008205	View Revisions
2010-06-12 12:35	DanielP	Note Edited: 0008205	View Revisions
2010-06-12 12:35	DanielP	Note Edited: 0008205	View Revisions
2010-06-12 12:36	DanielP	Issue Monitored: DanielP
2010-06-12 12:57	Footkerchief	Relationship replaced	has duplicate 0000243
2010-06-12 12:57	Footkerchief	Relationship added	parent of 0002254
2010-06-15 06:59	oliver	Note Added: 0008500
2010-06-15 07:01	oliver	Note Edited: 0008500	View Revisions
2010-06-15 14:30	Terisuke	Note Added: 0008529
2010-06-15 14:31	Terisuke	Note Edited: 0008529	View Revisions
2010-06-15 15:32	Footkerchief	Note Added: 0008534
2010-06-15 19:18	Footkerchief	Relationship added	parent of 0002347
2010-06-16 12:06	DanielP	Note Added: 0008563
2010-06-19 20:27	vwspeedracer	Note Added: 0008740
2010-06-22 18:22	Footkerchief	Relationship added	parent of 0000337
2010-06-22 18:22	Footkerchief	Sticky Issue	No => Yes
2010-06-23 21:36	bronwen	Note Added: 0009040
2010-06-24 07:38	greycat	Note Added: 0009047
2010-06-24 09:03	Footkerchief	Note Edited: 0009047	View Revisions
2010-06-27 19:44	Footkerchief	Relationship added	parent of 0002474
2010-06-29 09:55	Footkerchief	Relationship added	has duplicate 0002511
2010-07-05 05:07	uggi	Issue Monitored: uggi
2010-07-10 09:20	skeeve	Note Added: 0009884
2010-07-10 15:32	oliver	Note Added: 0009891
2010-07-12 11:43	Footkerchief	Relationship added	has duplicate 0002658
2010-07-12 12:49	Footkerchief	Relationship added	has duplicate 0002660
2010-07-12 12:49	Footkerchief	Note Added: 0010060
2010-07-13 05:39	Toady One	Relationship replaced	related to 0002254
2010-07-13 05:40	Toady One	Relationship replaced	related to 0000337
2010-07-13 05:40	Toady One	Note Added: 0010122
2010-07-13 05:40	Toady One	Status	new => resolved
2010-07-13 05:40	Toady One	Fixed in Version	=> 0.31.11
2010-07-13 05:40	Toady One	Resolution	open => fixed
2010-07-13 05:40	Toady One	Assigned To	=> Toady One
2010-07-14 22:10	Footkerchief	Relationship added	has duplicate 0002699
2010-07-18 01:56	Footkerchief	Relationship added	has duplicate 0002733
2010-07-19 13:45	Footkerchief	Sticky Issue	Yes => No
2010-07-20 07:13	Footkerchief	Relationship added	has duplicate 0002772
2010-07-26 07:14	uggi	Issue End Monitor: uggi
2010-07-28 15:21	Footkerchief	Relationship added	has duplicate 0002867
2010-08-08 12:11	Footkerchief	Relationship replaced	has duplicate 0002254
2010-08-27 01:42	Footkerchief	Relationship added	has duplicate 0001105
2010-08-27 01:43	Footkerchief	Relationship added	has duplicate 0000955
2010-08-27 01:46	Footkerchief	Relationship added	related to 0003109
2010-11-18 13:15	Footkerchief	Relationship added	related to 0001298
2011-03-19 18:15	Footkerchief	Relationship added	related to 0003201

Notes
(0001717) oliver (reporter) 2010-04-07 04:35	I was going to attach a screenshot, but I can't find the interface to attach files to an issue!

(0001718) Footkerchief (manager) 2010-04-07 04:36	A screenshot doesn't matter as much as reproducibility. It would be helpful if you determined whether this can be reproduced, and how.

(0001719) oliver (reporter) 2010-04-07 04:40	I also preserved the dump generated when I terminated the process (hdmp/mdmp files) if that's useful - I'm not familiar with debugging under Windows - but they are ~300MB in total so I will need to arrange to transfer them directly to someone who can use them.

(0001721) Footkerchief (manager) 2010-04-07 04:47	A full memory dump is overkill -- all that's really needed is the Dr Watson log file or user.dmp file -- but you could upload the dump here http://www.zshare.net/ [^]

(0001723) oliver (reporter) 2010-04-07 05:03	Ok - as I said I know nothing about the mechanics of debugging under windows - so what exactly do I need to send? I have (stolen from the info in the "do you want to tell microsoft all your secrets" process-termination dialog): dwarfort.exe.mdmp - 13MB dwarfort.exe.hdmp - 291MB appcompat.txt & manifest.txt which just look like metadata. Which of these are needed, or is there another dump I should be looking for?

(0001725) Footkerchief (manager) 2010-04-07 05:24	Uploading the mdmp file should be enough.

(0001909) Nighteyes (reporter) 2010-04-07 18:55	I think that you have found the cause of the crash that I posted (0000243) Sounds like the same symptoms, but you got far more detail then I found. I found that if I loaded the save the same thing would happen. I may still have the save but I'd have to go hunting.

(0002307) Rafal99 (reporter) 2010-04-09 05:21	Also related to: 0000869

(0006234) foxbyte (reporter) 2010-05-05 20:44	I just got something similar to this. After a fight with a titan I tried to cancel the orders of my squads [I had to use Move to fight the thing, since if I ordered them to Kill it they would all run back down to the barracks and re-arrange their equipment] but instead of assigning the orders to the entire group it kept forcing me to give orders to individuals. Then when I used /*-+ to go through the menu, the program froze up solid. There's no amount of magma that can unfreeze DF. :(

(0008205) DanielP (reporter) 2010-06-12 12:13 edited on: 2010-06-12 12:35	I had the same issue today in 0.31.06, after I tried to give a dwarf a separate move order. http://www.bay12games.com/dwarves/mantisbt/view.php?id=2254 [^] is probably also the same issue.

(0008500) oliver (reporter) 2010-06-15 06:59 edited on: 2010-06-15 07:01	I saw this again today under .06, using the Linux version. Unfortunately I didn't think to grab a coredump when it hung. Next time I'll try to do that. It's not frequent, I've only seen it twice. Possibly the trigger is related to giving individual orders to members of a squad - I don't commonly do that, but I was using individual orders just before both crashes.

(0008529) Terisuke (reporter) 2010-06-15 14:30 edited on: 2010-06-15 14:31	I have been able to reproduce this crash by accessing the squads screen after assigning individual station orders. I saved right before the squad assignment, so I tried to do it again, again getting the crash. My actions each time were: Assign Stations to one member from each of two squads Combat ensues View reports, then return to main screen. Attempt to pull up squad interface - causes crash. EDIT: 0.31.06, Mac OSX

(0008534) Footkerchief (manager) 2010-06-15 15:32	Do those actions reliably produce a crash on ANY save? If not, it would be helpful for you to upload your save to http://dffd.wimbli.com/ [^]

(0008563) DanielP (reporter) 2010-06-16 12:06	At least for my current fortress I could reproduce it for different years and with different squads, but apparently the squad has to be active before assigning the individual station orders. It also happened with a squad, which had only one member.

(0008740) vwspeedracer (reporter) 2010-06-19 20:27	Just experienced this in 31.08 when sending an individual bowman to kill a goat. (He was pretty unhappy so I figured some blood and guts would cheer him up.) Unfortunately it's been nearly a season since my last save, so I don't have a useful file. Win7x64, taskman showing nonresponsive with 100% usage of the core it's running on, so some sort of loop or runaway?

(0009040) bronwen (reporter) 2010-06-23 21:36	I experienced this in 31.08 when trying to cancel the kill order for a giant mole. I had 2 squads, had successfully cancelled one squad's orders, found the dead mole and confirmed it was dead then attempted the cancel the other squad's orders. I believe I hit the wrong key a few times and then when I hit the right key, DF hung. However earlier in the game I had no problems using the squad menu in pretty much exactly the same way (only it was for alligators).

(0009047) greycat (reporter) 2010-06-24 07:38 edited on: 2010-06-24 09:03	I just got this too. 31.08 under Linux (Debian 5.0). I had one dwarf actively fighting against an unkillable forgotten beast (made of salt - I'd chopped all four of its feet off, but several months of chopping at it everywhere, including several instances of twisting an embedded steel axe in its head, weren't doing any additional damage). I had just sent another dwarf (part of a squad, but sent individually) to get some weapon and armor practice as well. I pressed 's' again, and I think that's when the entire process hung. Other things that were occurring at the same time included one dwarf making an artifact (in a craftdwarf's shop), and some elves hanging out at the depot, having just been traded with. Plus assorted dwarvery. Attaching with gdb gives this: (gdb) bt #0 0xb80ae424 in __kernel_vsyscall () #1 0xb79313b5 in sem_wait@@GLIBC_2.1 () from /lib/i686/cmov/libpthread.so.0 #2 0xb804dd98 in SDL_SemWait () from /usr/lib/libSDL-1.2.so.0 #3 0xb7bf7c96 in enablerst::async_wait () from /home/wooledg/df_linux/libs/libgraphics.so #4 0xb7bf8117 in enablerst::do_frame () from /home/wooledg/df_linux/libs/libgraphics.so #5 0xb7bf8379 in enablerst::eventLoop_SDL () from /home/wooledg/df_linux/libs/libgraphics.so #6 0xb7bf9015 in enablerst::loop () from /home/wooledg/df_linux/libs/libgraphics.so #7 0xb7bf9862 in main () from /home/wooledg/df_linux/libs/libgraphics.so #8 0xb7954455 in __libc_start_main () from /lib/i686/cmov/libc.so.6 #9 0x0804d011 in ?? () I don't know how helpful that is. The process is eating CPU. Reproduceability is nil. :(

(0009884) skeeve (reporter) 2010-07-10 09:20	df 31.08, win7 64bit Just seen the same thing. It seems i can reproduce this so : assign a kill order to squad/individual -> unpause -> wait til the attacked creature has left the map -> press "s" for squad screen. -> hang. I 'm not entirely sure, but i get "same hanging" with appointed military captains assinged to squads. Then remove captain from noble screen. Then pressing "m" for military screen it hangs.

(0009891) oliver (reporter) 2010-07-10 15:32	@greycat: FWIW, under SDL versions, you actually want a stacktrace from a different thread, not the main thread. The main thread is just doing rendering; the simulation (which has hung) runs in a separate thread. The stacktrace above just shows the rendering thread is waiting for the simulation thread to complete simulation of the next frame. Try "thread apply all bt" under gdb.

(0010060) Footkerchief (manager) 2010-07-12 12:49	From 0002660: Save: http://dffd.wimbli.com/file.php?id=2668 [^] I use mayday graph. pack. 1) Press "s" and command them to go somewhere 2) Wait for 4-5 minutes 3) Try to hit "s" again. Sometimes it crashes, sometimes it doesn't

(0010122) Toady One (administrator) 2010-07-13 05:40	This one has been fixed for 0.31.11. Until then, when you give individual orders to squads, it'll be safest if you unselect any individuals before leaving the squad menu. The crash can come when it tries to make your old selection persist and a loop is indexed wrong.