View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0001128Spring engineGeneralpublic2008-10-13 16:392008-10-16 18:02
ReporterBug Hunter Assigned ToKloot  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Product Version0.77b2 
Summary0001128: Crash watching replay.
DescriptionGot a crash watching this replay, in the first minute:

http://replays.adune.nl/?266

uploading infolog
TagsNo tags attached.
Attached Files
infolog.txt (Attachment missing)
infolog2.txt (Attachment missing)
crash_r6706.sdf (Attachment missing)
Checked infolog.txt for Errors

Relationships

related to 0001127 resolvedKloot Crash in 77b3, infolog here 

Activities

Bug Hunter

2008-10-13 16:44

reporter   ~0002844

Watching this another replay does generate a crash aswell:

http://replays.adune.nl/?265

uploading infolog.

Kloot

2008-10-13 17:02

developer   ~0002845

Last edited: 2008-10-13 17:04

 infolog and infolog2 contain (almost) the same trace as 1127. Next time please check for similarity with those issues before submitting a new report, three or more of the same problem are unncessary and harder to keep track of.

imbaczek

2008-10-13 18:04

reporter   ~0002847

could you export your spring settings registry key and attach it here?

Kloot

2008-10-13 22:03

developer   ~0002850

Last edited: 2008-10-13 22:05

 Cause seems to be an iterator increment past end(), it triggered an assert I had added. Simpe bounds-check before the ++ should be enough.

imbaczek

2008-10-13 22:09

reporter   ~0002852

Kloot, if you're patching this, feel free to remove noop check that I hastily added in r6702. it does nothing AFAICT.

Kloot

2008-10-13 23:05

developer   ~0002855

Cheers, done. Needs some major testing before I'll sign off on it this time though. ;)

imbaczek

2008-10-13 23:07

reporter   ~0002856

Last edited: 2008-10-13 23:09

 mmgr says it started to leak memory now.

edit: i think i had an old build, i'll check out the new one.

imbaczek

2008-10-13 23:13

reporter   ~0002857

Last edited: 2008-10-13 23:16

 woah i just crashed it in line 450, testing something completely different...

edit: crash at std::_Rb_tree_const_iterator<BuildingGroundDecal*>::operator--(int).

Kloot

2008-10-13 23:15

developer   ~0002858

Last edited: 2008-10-13 23:17

 Incidentally, I've just noticed a similar pattern exists in the inner footprint decal loop, so once (if) 6706 is confirmed to work I'll apply it there as well.

EDIT: doh... the decrement has to be guarded against underflow now

imbaczek

2008-10-13 23:21

reporter   ~0002859

Last edited: 2008-10-13 23:23

 uploaded replay crashes reliably for me. btw is it safe to inc/decrement an erased iterator? i'm not so sure about that.

Kloot

2008-10-13 23:29

developer   ~0002860

Last edited: 2008-10-13 23:29

 Well, if it's not, then incrementing wouldn't have been safe either, but I'm not 100% sure about that myself. Testing something now for confirmation.

Kloot

2008-10-13 23:33

developer   ~0002861

STL docs say "Erasing an element from a set also does not invalidate any iterators, except for iterators that actually point to the element that is being erased" so ++/-- are indeed off-limits.

imbaczek

2008-10-13 23:36

reporter   ~0002862

replay still crashes for me in r6708.

Kloot

2008-10-13 23:52

developer   ~0002864

Last edited: 2008-10-13 23:56

 Not that I can really think straight anymore, but I'm pretty sure it's fixed now (6711). Apologies for the mess.

imbaczek

2008-10-14 20:49

reporter   ~0002892

in case it's not, and i've got a hunch we haven't seen the last of it, what was the assert that triggered for you, kloot?

Kloot

2008-10-14 21:15

developer   ~0002893

I had an

    assert(!buildingDecals.empty())

before the call to erase(it++) was made, I think.

Kloot

2008-10-16 18:01

developer   ~0002963

There have been no further reports about this since 77b4, so I'm going to give it the benefit of the doubt now. We'll know soon enough if that isn't warranted since these reports were so widespread people are bound to run into the crash again if it actually hasn't been fixed yet.

Issue History

Date Modified Username Field Change
2008-10-13 16:39 Bug Hunter New Issue
2008-10-13 16:39 Bug Hunter File Added: infolog.txt
2008-10-13 16:44 Bug Hunter Note Added: 0002844
2008-10-13 16:45 Bug Hunter File Added: infolog2.txt
2008-10-13 17:02 Kloot Note Added: 0002845
2008-10-13 17:02 Kloot Relationship added related to 0001127
2008-10-13 17:03 Kloot Note Edited: 0002845
2008-10-13 17:04 Kloot Note Edited: 0002845
2008-10-13 18:04 imbaczek Note Added: 0002847
2008-10-13 22:03 Kloot Note Added: 0002850
2008-10-13 22:05 Kloot Note Edited: 0002850
2008-10-13 22:09 imbaczek Note Added: 0002852
2008-10-13 23:05 Kloot Note Added: 0002855
2008-10-13 23:07 imbaczek Note Added: 0002856
2008-10-13 23:09 imbaczek Note Edited: 0002856
2008-10-13 23:13 imbaczek Note Added: 0002857
2008-10-13 23:15 Kloot Note Added: 0002858
2008-10-13 23:16 imbaczek Note Edited: 0002857
2008-10-13 23:17 Kloot Note Edited: 0002858
2008-10-13 23:20 imbaczek File Added: crash_r6706.sdf
2008-10-13 23:21 imbaczek Note Added: 0002859
2008-10-13 23:23 imbaczek Note Edited: 0002859
2008-10-13 23:29 Kloot Note Added: 0002860
2008-10-13 23:29 Kloot Note Edited: 0002860
2008-10-13 23:33 Kloot Note Added: 0002861
2008-10-13 23:36 imbaczek Note Added: 0002862
2008-10-13 23:52 Kloot Note Added: 0002864
2008-10-13 23:55 Kloot Note Edited: 0002864
2008-10-13 23:55 Kloot Note Edited: 0002864
2008-10-13 23:56 Kloot Note Edited: 0002864
2008-10-14 20:49 imbaczek Note Added: 0002892
2008-10-14 21:15 Kloot Note Added: 0002893
2008-10-16 18:01 Kloot Note Added: 0002963
2008-10-16 18:02 Kloot Status new => resolved
2008-10-16 18:02 Kloot Resolution open => fixed
2008-10-16 18:02 Kloot Assigned To => Kloot