Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0011014Dwarf FortressDwarf Mode -- Militarypublic2019-01-27 17:392019-09-29 16:39
ReporterLoci 
Assigned ToLoci 
PriorityhighSeveritycrashReproducibilitysometimes
StatusconfirmedResolutionopen 
PlatformOSOS Version
Product Version0.44.12 
Target VersionFixed in Version 
Summary0011014: Reproducible crash from corrupted military equipment lists
DescriptionThe attached save is on the 25th of Mid-Autumn. It crashes reliably at the end of the month.

I haven't been able to isolate the source of the crash.

On a potentially-related note, the save shows two merchants leading pack animals into dead-end rooms of the fortress.
Additional Informationhttp://dffd.bay12games.com/file.php?id=14213 [^]


*edit: risusinf identified this crash as a corruption of military equipment and linked multiple other examples in note 0011014:0039186 below.
TagsNo tags attached.
Attached Files

- Relationships
related to 0010951confirmedLoci Crash After Multiple Conquest Missions 
related to 0011156confirmedLoci Unavoidable crash related to picking up equipment 
parent of 0010880confirmedLoci Segmentation fault, reproducible via save state 
parent of 0010868confirmedLoci Vanilla 0.44.12 crash in seconds. 
parent of 0010975new Crashes when a human caravan leaves map 
parent of 0010911new The referenced save game crashes after just over 10 seconds 
parent of 0010894new Seg Fault. 
parent of 0010851confirmedLoci Crash (unknown trigger) 
parent of 0011025new Invading army causes crash around the same time a hillocks is established. 
parent of 0011040new Game will crash after a few minutes of unpausing 
parent of 0011085new Crash when merchants leave map 
parent of 0011131new Consistent crash about 15s after loading this save 
parent of 0011141new Game crashes when squad returns from raid 
parent of 0011100new Game crashes as soon as bard visits 
Not all the children of this issue are yet resolved or closed.

-  Notes
(0039161)
PatrikLundell (reporter)
2019-01-28 00:36
edited on: 2019-01-28 00:37

I've tried the save twice, without crashing in either case, so I assume the issue requires a specific environment.
I'm on Windows 10.1 using the LNP r05.

In my first attempt I had DFHack enabled. The merchant ran back and forth like visitors do when trying to leave a fortress whose entrances are all locked up due to a siege so there's no path out. Eventually the merchant disconnected from the yak in a room in the fortress without any indication of a reason (no fighting or fear, as far as I could see) and eventually left through a cavern together with the swordsman. When I killed the game around the 10:th the yak remained in the fortress labeled as "Friendly" rather than "Merchant".

In my second run I'd disabled DFHack (and changed print mode from TwbT to 2D). In this run the merchant left the fortress on the surface together with the yak at around the 4:th. The swordsman turned to "Friendly", but left shortly thereafter.

If it's of interest, I can let the fortress run on its own past the troublesome end of the month and upload the progressed save to allow you to continue (if so, please specify a time you'd like the save to be progressed to).

(0039175)
Loci (manager)
2019-02-02 10:02
edited on: 2019-02-02 10:05

Thank you for taking a look at the save. It crashes reliably for me using vanilla windows x32, vanilla linux x64, and vanilla windows x64 under wine. The only common thread I see is an AMD processor.

Given the nature of the failure, I suspect the crash will likely recur at the end of subsequent months, but if you are willing to post a save after the first of Timber I'll test that hypothesis.

(0039181)
PatrikLundell (reporter)
2019-02-03 00:37

http://dffd.bay12games.com/file.php?id=14227 [^] progressed to the second of Timber.
I've done nothing except looking at Announcements from time to time to check progress, so no actions have been taken (I haven't even checked on the erratic merchant this time).

My PC has an Intel processor, so that doesn't contradict the hypothesis of the issue being AMD related.
(0039183)
risusinf (reporter)
2019-02-03 08:35
edited on: 2019-02-03 21:35

Does segfault on lin32 old Intel CPU and doesn't on win64 modern Intel CPU (noticed a moment of stuttering though), but that's not the point. Crash isn't time fixed and can be avoided. It doesn't happen when all squads are disbanded, so i believe the issue is the same as i reported in 0010880:0038940, namely military equip lists being completely fucked up. Illustration: https://i.imgur.com/VKTGasZ.png [^] (it is relatively easy to check any crashy save for this to be the reason)

Probably this should be prioritized due to its unholy ugliness and that the issue is likely to cover several tickets on the tracker, not to say it breaks gameplay, you can't have proper militia anymore.

Next day edit: I'm going to check few more unresolved crash reports to see how widespread the issue could be.

(0039185)
PatrikLundell (reporter)
2019-02-05 03:52

I just had a case of this crash myself a couple of seconds after quicksaving. Disbanding all squads did indeed allow the game to progress, while disbanding no single squad did. Checking specific Armor showed a bunch of written contents (all "item_bookst") at the bottom (and the one I checked wasn't in my fortress). The only category whose specific item list wasn't cluttered with "item_bookst" was the Weapon one, which doesn't seem to be broken (in my particular case). It can be noted that the junk items at the end differ between the equipment categories, but contain at least one item in common, and probably several ones. This item also appears multiple times in the lists (at least most of them). However, progressing the game for a few seconds and attempting to create a squad shows that the categories have not been repaired, but retain the junk items. Since my fortress was built on the idea of conquering goblin sites, this is really a fatal blow to it.

All the "books" I've looked at have had low item Ids, typically around 6-700.
(0039186)
risusinf (reporter)
2019-02-05 08:46

Few saves that follow the same pattern
All tests were carried out on intel i7 lin64 platform (through ssh) with vanilla DF 0.44.12

Read each paragraph line by line as:
- Ticket/comment ID
- Result of the first run
- Actions on the second run to avoid and reproduce crash
- Garbage in equip lists ( [m]->[e]->[A|L|H|G|B|S|W]->"specific ..." )
- Additional notes

0011014
crash time ~1min (win64 same CPU no crash)
reload and disband all squads before unpausing; no crash after 2min; quick crash after creating 1 unit squad with "footwear" equipped
Helm=Ivaklasod x1; Boots=Ivaklasod x4; Shield=Ivaklasod x1
Ivaklasod is a serpentine slab, first item in the legends mode's Codices menu
(Garbage items come and go with time, compare https://i.imgur.com/VKTGasZ.png [^] which was made on the first run before unpausing the game)

0011004
crash time ~2min (win64 same CPU no crash)
reload and disband all squads before unpausing; no crash after 5min; quick crash after creating 1 unit squad with "armor" equipped
Armor=Måmgozôm îbmat Lisid x3; Boots=Måmgozôm îbmat Lisid x100, ≡large smoky quartz≡ x2, Soshornalthish x1
Måmgozôm îbmat Lisid is a sterling silver slab, first item in the legends mode's Codices menu

0010880:0038940 (win64 same CPU does crash)
crash time <1min
reload and disband all squads before unpausing; no crash after 1min; quick crash after creating 1 unit squad with "handwear" equipped
Legs=Sesiwerima Obenirifi x1, The World Without The Wind x1; Gloves=Sesiwerima Obenirifi x2, Classic Fikod Gearedfocused x1, Life With Beakers x1
Sesiwerima Obenirifi is a microcline slab, first item in the legends mode's Codices menu
(this one is mine, crashes the same way on lin32 old Intel CPU platform)

0010880:0038892
crash time <2min (win64 same CPU no crash)
reload and disband all squads before unpausing; no crash after 5min; quick crash after creating 1 unit squad with "headwear" equipped
Helm=Slömodoxxo x1; Gloves=Slömodoxxo x2
Slömodoxxo is an hornblende slab, second item in the legends mode's Codices menu

0010880
crash time <5min (win64 same CPU no crash)
reload and disband all squads before unpausing; no crash after 10min; quick crash after trying to check "specific armor" list
Armor=Thafenelara x1
Thafenelara is a rhyolite slab, first item in the legends mode's Codices menu

0010868
crash time <1min (win64 same CPU no crash)
reload and disband all squads before unpausing; no crash after 1min; quick crash after creating 1 unit squad with "armor" equipped
Armor=Okoshfeb x2; Legs=Okoshfeb x2; Helm=Okoshfeb x3; Gloves=Okoshfeb x1; Shield=Okoshfeb x4; Weapon=Okoshfeb x2
Okoshfeb is a native gold slab, first item in the legends mode's Codices menu

Timings and the crashes itself (which might not happen at all) depend on CPU performance and architecture (and god knows what else, OS for sure)
All crashes are SEGFAULT
The issue may be responsible for multiple raid-related reports, i haven't checked those yet though (tested saves has no "travelling" dwarves), and if so this bug grows even bigger in its terrible awfulness (no, i cannot approve that Windows seemingly tends to sweep under the rag flawed code)
(0039187)
Loci (manager)
2019-02-05 13:43

@PatrikLundell: Thank you for uploading the advanced save! I was able to run it without crash for over a year, so loading and resaving a few days later somehow fixed the corruption, at least temporarily.

@risusinf: Thank you for the detailed analysis! This issue is likely to be one of the first few bug-fixes after the upcoming release, and your efforts will help Toady identify and correct the problem.
(0039191)
risusinf (reporter)
2019-02-06 08:04

More abominations

0010975
crash time ~1min
reload and disband all squads before unpausing; no crash after 2min; quick crash after trying to check "specific gloves" list
NO visual garbage in equip lists
0010579 might be the same, but it crashed only once in multiple attempts

0010911
crash time <1min
reload and disband all squads before unpausing (including one with travelling dwarves); no crash after 2min; no crash after creating 1 unit squad with "armor" equipped, then adding "legwear", then "helm", but eventually crashed after adding "handwear"
Armor=For The Love Of The Individual x15, For The Love Of The Fortress x1; Legs=For The Love Of The Individual x7; Helm=For The Love Of The Individual x7; Gloves=An Offering To The Truth x1; Boots=For The Love Of The Individual x15, Taremimustteling x2; Shield=For The Love Of The Individual x6
Taremimustteling is a native copper slab, first item in the legends mode's Codices menu

0010894
crash ~2min, soon after a squad returns from mission
disbanding squads except the returning one still crashes, while disbanding it too right on arrival keeps the game running; quick crash after creating 1 unit squad with "armor" equipped
Armor=Asolum âtrid Vetek x2; Legs=Asolum âtrid Vetek x5; Helm=Asolum âtrid Vetek x5; Gloves=Asolum âtrid Vetek x2; Boots=Asolum âtrid Vetek x10; Shield=Asolum âtrid Vetek x5; Weapon=Asolum âtrid Vetek x1
Asolum âtrid Vetek is a diorite slab, first item in the legends mode's Codices menu

0010851
crash time <1min
after disbanding squads game goes past, and goblins arrive; couldn't reproduce crash by adding equip categories for 1 unit squad
Armor=Slatsutosnak x1; Legs=Slatsutosnak x1; Helm=Slatsutosnak x1; Gloves=For The Love Of The Tower x1, Thoughts On The Elf x1; Shield=Slatsutosnak x2; Weapon=Slatsutosnak x2
Slatsutosnak is bituminous coal slab, first item in the legends mode's Codices menu

That would be all for my crusade against evil, but i guess there is a huge ton of saves affected, as the most popular Windows platform just keeps it low profile, and sometimes the impact is not too harsh
(0039193)
Gregamesh (reporter)
2019-02-06 22:49
edited on: 2019-02-07 11:06

Going to add to this because I realized that the last issue I posted is actually another example of equipment list corruption:

All are run on DF 0.44.12 on Mac OS High Sierra, version 10.13.6. I could try again with an updated OS, but I doubt it will change things.

Original report of mine: 0011025
Crashes in about 1 min (2 in-game days, exactly)
Disbanding all squads does not result in an immediate crash.

Corrupted armors are as follows:
Armor=Snogongstekug x1, Unookal x1; Legs=no corruption; Helm=Unookal x1, Inquires on the Center x1; Gloves=Snogongstekug x2, Unookal x1; Boots=Snogongstekug x1, Unookal x1; Shields=no corruption; Weapons=no corruption.
Unookul is the first entry in Codices, etc; it is an orthoclase slab.
Snogongstekug is the second entry; it is a chalk slab.

A save created by retiring the fort at this point and unretiring does not have any armor list corruption. I have not tested if armor corruption will eventually develop in that version of the save.


By saving repeatedly on the date when a segfault would occur, I was able to push the save until 773-8-11. Advanced version of the save can be downloaded here: http://dffd.bay12games.com/file.php?id=14236. [^] At this point, saving on or after 8-12 results in the following error:
[DFHack]# /Users/{my directory}/Desktop/df_osx/dfhack: line 15: 5033 Abort trap: 6 DYLD_INSERT_LIBRARIES=./hack/libdfhack.dylib ./dwarfort.exe "$@"

Letting the game run instead, it crashes around 8-17 with the following error:
[DFHack]# /Users/{my directory}/Desktop/df_osx/dfhack: line 15: 4930 Segmentation fault: 11 DYLD_INSERT_LIBRARIES=./hack/libdfhack.dylib ./dwarfort.exe "$@“
Note: the 4-digit number changes between each iteration of the crash, but the rest of the message remains the same.

Disbanding all squads but the eighth (it is leaving to go on a raid, and the commander is off-site) allows normal saving to occur after the 12th. Squads can be recreated after this point and saved normally. Squads were recreated using a premed equipment template with parts from all categories. The game still segfaults around 8-17.

The corrupted armors in this version of the save are:
Armor=Snogongstekug x1, Unookal x1; Legs=no corruption; Helm=Unookal x1, Inquires on the Center x1; Gloves=Snogongstekug x4, Unookal x2; Boots=Snogongstekug x1, Unookal x1; Shields=no corruption; Weapons=no corruption.

(0039207)
risusinf (reporter)
2019-02-11 22:56
edited on: 2019-02-13 03:15

Regarding possible obstructions of the raid system

0010951
Resaving postpones crashing, and equip lists are heavily corrupted (behaviour similar to 0011014). This resave (made immediately after the conquest of Mighthorror) -- http://dffd.bay12games.com/file.php?id=14246 [^] -- reliably crashes for me in under 3min (44.12@lin64, win64 doesn't seem to crash at all). Military layout is complicated. One squad is out for a mission with two recruits falling behind, one of them has no military equipment and is about to pick it up. Disbanding all other squads (including one with travelling dwarves from the previous mission) makes it crash even faster (<1.5min). Removing the guy without equipment from the squad doesn't change anything, removing both recruits allows the game to show message about successfull conquest and then crash shortly. After that my best guess was that the travelling squads can actually trigger the equipment bug, or there is something else, so i kept digging. Weirdly enough, i discovered that terminaton of all of the yaks at once allows to progress for 5min and maybe more. However, killing off yaks one by one didn't make the crash go away. More to this, guy from The Eradicators, position 1 and another one from The Crosshoes, position 2 are assigned to equip two "missing item" each; and all members of The Golden Legion are assigned to wear socks, which is weird. Related or not, but it's a total mess.

Also there is a small inconsistency in viewing departed squads on the military screen: [p]ositions shows members names with (travelling) postfix while [e]quip instead of that prints VACANT/AVAILABLE.

============

EDIT:
After getting familiar with 0010369 i tend to assume that all these memory corruptions are actually just a further development of some general flaw in the raiding system itself, as that issue wasn't solved but patched out by checking and removing duplicate items.

(0039229)
Darxus (reporter)
2019-02-20 16:09

Gregamesh said mine might be related: 0011035

I load it, save immediately, and it crashes, every time. They mentioned I have armor corruption similar to stuff mentioned here. On my dwarves out on a raid.
(0039342)
Galap (reporter)
2019-04-20 23:19

The workaround I've found that works (albeit tediously) so far is to assign every soldier specific items instead of anything generic, and have it replace clothing, exact matches. Basically If you tell them exactly what to equip, they will never try to put on the bugged items.
(0039349)
risusinf (reporter)
2019-05-03 00:08

After a recent small discovery at 0011085, i got back to revise the save from 0010975, which stands out for having no usual symptoms of 0011014 corruption (slabs, books, etc), and indeed there was more to that. "Weapon" category has (large iron right gauntlet) somewhere in the middle for some reason. Still unclear what is going on, but catching the moment when equipment goes wild now seems to be theoretically possible, but goddamn i am reluctant to try.
(0039356)
risusinf (reporter)
2019-05-07 09:03
edited on: 2019-05-11 20:37

Started a new fort the other day just to investigate the problem further. Kept it really simple and minimalistic with low population cap, so any kind of invasion never was triggered, nothing happened but peaceful economic growth, squad training and equipping and some occasional traiding. When the squad was set up, i decided to roll them out for the first time, and checked equipment lists before that just to make a reference point.

https://i.imgur.com/1WBSEDr.png [^]

Few quick notes before i'm too tired:
1. Reds are obviously squad equipment
2. Civilian clothing worn or claimed by fort citizens are not present
3. (+steel mail shirt+) probably was traided by accident
4. Most of the remaining items are "large" but:
     a) i have never bought anything "large"
     b) i have no human residents, all petitions were denied
     c) there are few human visitors, and it seems they are wearing those items
     d) there are few dwarven visitors, but their clothing is not present

The situation is explosive if i am getting it right. There might be something else as i see some discrepancies in handwear/footwear sections, but i'm leaving it for the next time. Thoughts?

============

"Large" items indeed belong to four human visitors, the rest is just unowned tattered clothing which is expected to be in the lists. Two dwarven visitors don't cause anything unusual. Also, when squad leaves the map those red lines (i.e. assigned equipment) disappear in every category (except "boots", and that's because of my overlook -- dwarves apparently can't wear high boots with leggings, and never put boots on), and they never reappear even after squad is back home.

============

Human visitors: all their items are in equip lists and not forbidden. When manually forbidden they don't get listed.
Human merchants: everything in their inventory initially forbidden, and will be available in equip lists when unforbidden.
Dwarven visitors: all their items are not forbidden, and only military equipment gets listed.

============

It's not like you send out a squad and it breaks down. There are some conditions, but those i can't figure out. Couple of sidenotes:
* Merchants' goods show up in the lists after "merchants have embarked on their journey" announcement
* (unrelated) Dumped into magma items don't get destroyed until they reach the bottom of magma sea
* (large iron right gauntlet) from 0010975 that somehow counts as "weapon" can be found in one of the human traiding wagons.When forbidden it disappears from equip lists, but the game crashes regardless.
* In my previous fort (0010880:0038940) i found two human bard with completely empty inventories. Their extermination changes nothing.
* Regarding the situation with high boots, the human merc who came in with both high boots and leggings equipped, succesfully replaced all of his equipment with the new one i made for him, except for his old high boots, which he refuses to change.

So the bottom line as i see it at the moment is that there is a combination of two issues. Firstly, the filters for equip lists are quite loose, they allow too much items that shouldn't be there. Secondly, somehow traveler units get corrupted (0010939 et al, 0010369 -- units offloading broken?).

(0039359)
minorukun (reporter)
2019-05-08 12:23

faced this bug too after one and only raid. Some investigation in exported legends stated that item that appeared in every equipment lists is world's first artifact #0 - some slab, created by demon. Maybe memory structures/indexes/boundaries/whatnot starts to overlap from there?
(0039398)
hyndis (reporter)
2019-06-20 13:14

I'm also seeing this. The game is 100% stable until I start sending squads off to raid, then once the squad gets back its crash city. Instant crash to desktop. The game just dies immediately and randomly, but also so frequently its unplayable.

Disbanding my military squads and rebuilding them seems to fix the issue. I can play stable and without problems after that. The cause and fix of this crash bug is pretty much 100% reproducible.

Is there any solution to this other than simply don't send any dwarves off map?

Can I change the uniform once they get home? Immediately switch out the uniform to something else? Will sending naked dwarves with a uniform that replaces all items fix the issue? Dwarves out on raids only seem to use combat stats, not weapons, so equipment might not matter at all. Or do squads sent out need to be one time things? Make a squad, send it out, and then upon return immediately disband it only to make a new squad?

How can I use the world map system in fortress mode without crashing? What should I do as a workaround?
(0039399)
risusinf (reporter)
2019-06-20 20:52

All we know is that travelling (not only for squads, might affect fort visitors as well) somehow corrupts equip lists (and visitors equipment in that case), and after that happened it is unsalvageable (bugged visitors could be just exterminated though). Ability to rebuild squads might be platform dependant. On linux game dies rather quickly if you do so.
(0039405)
hyndis (reporter)
2019-06-30 01:44
edited on: 2019-06-30 01:45

Modding out clothing and setting up military uniforms so they replace the existing outfit and accepting exact matches only seems to have resolved this for me. I also set the armor type's material. So, mithril breastplate, mithril greaves, mithril gauntlets, etc.

I suppose this might also be because I added a new metal to the game; mithril. Only dwarves can make this metal. This means that all mithril helms are all exactly the same size. No large or small mithril helms will ever be generated. Therefore, by specifying mithril helm in the uniform screen there will never be an unwearable helm that a dwarf tries to equip.

By removing clothing and specifying material type and requiring exact matches with the uniform replacing clothes this has fixed the problem. My squads leave on raids and return without any crashes happening anymore. Zero crashes since I did this.

I'm still seeing some oddities where dwarves get very attached to artifact mugs and goblets. Once a dwarf picks up an artifact mug or goblet they never put it down regardless of military uniforms. They even use this artifact mug in combat, smacking goblins over the head with their named granite mug. No idea how to fix that one but at least it doesn't appear to crash the game. The mug is equipped in addition to any uniforms. A dwarf with a mug will use both their mug and battleaxe in combat as if they're dual wielding.

(0039519)
risusinf (reporter)
2019-09-29 09:40

0011100 remains unlinked.

- Issue History
Date Modified Username Field Change
2019-01-27 17:39 Loci New Issue
2019-01-27 17:44 Loci Additional Information Updated View Revisions
2019-01-28 00:36 PatrikLundell Note Added: 0039161
2019-01-28 00:37 PatrikLundell Note Edited: 0039161 View Revisions
2019-02-02 10:02 Loci Note Added: 0039175
2019-02-02 10:03 Loci Description Updated View Revisions
2019-02-02 10:05 Loci Note Edited: 0039175 View Revisions
2019-02-03 00:37 PatrikLundell Note Added: 0039181
2019-02-03 01:53 risusinf Note Added: 0039182
2019-02-03 08:35 risusinf Note Deleted: 0039182
2019-02-03 08:35 risusinf Note Added: 0039183
2019-02-03 08:36 risusinf Note Edited: 0039183 View Revisions
2019-02-03 21:34 risusinf Note Edited: 0039183 View Revisions
2019-02-03 21:35 risusinf Note Edited: 0039183 View Revisions
2019-02-05 03:52 PatrikLundell Note Added: 0039185
2019-02-05 08:46 risusinf Note Added: 0039186
2019-02-05 13:43 Loci Note Added: 0039187
2019-02-05 13:43 Loci Assigned To => Loci
2019-02-05 13:43 Loci Priority normal => high
2019-02-05 13:43 Loci Reproducibility always => sometimes
2019-02-05 13:43 Loci Status new => confirmed
2019-02-05 13:43 Loci Category General => Dwarf Mode -- Military
2019-02-05 13:43 Loci Summary Reproducible crash at end of month => Reproducible crash from corrupted military equipment lists
2019-02-05 13:43 Loci Additional Information Updated View Revisions
2019-02-06 08:04 risusinf Note Added: 0039191
2019-02-06 22:49 Gregamesh Note Added: 0039193
2019-02-06 22:49 Gregamesh Note Edited: 0039193 View Revisions
2019-02-06 22:50 Gregamesh Note Edited: 0039193 View Revisions
2019-02-07 11:06 Gregamesh Note Edited: 0039193 View Revisions
2019-02-11 22:56 risusinf Note Added: 0039207
2019-02-12 09:29 risusinf Note Edited: 0039207 View Revisions
2019-02-13 03:12 risusinf Note Edited: 0039207 View Revisions
2019-02-13 03:15 risusinf Note Edited: 0039207 View Revisions
2019-02-15 02:07 risusinf Issue Monitored: risusinf
2019-02-20 16:09 Darxus Note Added: 0039229
2019-02-24 12:01 Loci Relationship added parent of 0010880
2019-02-24 12:02 Loci Relationship added parent of 0010868
2019-02-24 12:03 Loci Relationship added parent of 0010975
2019-02-24 12:04 Loci Relationship added parent of 0010911
2019-02-24 12:05 Loci Relationship added parent of 0010894
2019-02-24 12:06 Loci Relationship added parent of 0010851
2019-02-24 12:07 Loci Relationship added parent of 0011025
2019-02-24 12:11 Loci Relationship added related to 0010951
2019-03-02 11:48 Loci Relationship added parent of 0011040
2019-04-20 09:23 Loci Relationship added parent of 0011085
2019-04-20 23:19 Galap Note Added: 0039342
2019-05-03 00:08 risusinf Note Added: 0039349
2019-05-07 09:03 risusinf Note Added: 0039356
2019-05-08 02:14 risusinf Note Edited: 0039356 View Revisions
2019-05-08 11:34 minorukun Issue Monitored: minorukun
2019-05-08 12:23 minorukun Note Added: 0039359
2019-05-09 04:48 risusinf Note Edited: 0039356 View Revisions
2019-05-10 05:56 risusinf Note Edited: 0039356 View Revisions
2019-05-11 03:00 risusinf Note Edited: 0039356 View Revisions
2019-05-11 20:37 risusinf Note Edited: 0039356 View Revisions
2019-06-20 13:14 hyndis Note Added: 0039398
2019-06-20 20:52 risusinf Note Added: 0039399
2019-06-30 01:44 hyndis Note Added: 0039405
2019-06-30 01:45 hyndis Note Edited: 0039405 View Revisions
2019-07-29 16:26 Loci Relationship added parent of 0011131
2019-08-18 12:33 Loci Relationship added parent of 0011141
2019-09-24 10:49 Erei Issue Monitored: Erei
2019-09-24 10:49 Erei Issue End Monitor: Erei
2019-09-29 09:40 risusinf Note Added: 0039519
2019-09-29 16:38 Loci Relationship added parent of 0011100
2019-09-29 16:39 Loci Relationship added related to 0011156


Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker