Weird Crashes
Moderators: Flumminator, Zomis
- Rockford4ever
- Posts: 152
- Joined: Tue Jan 03, 2006 7:41 pm
- Location: Belgium
Weird Crashes
I was playing Arno Luppolds level set (contribution levels) and in the first level, I was walking to the right on a huge empty space full of robots, and suddenly RnD crashed. Could anyone try to reproduce this? (Win XP, rnd-3.2.4)
EDIT: I was just editing that level and it crashed again! Weird... Also, by crashing, I mean shutting down automatically.
EDIT: I was just editing that level and it crashed again! Weird... Also, by crashing, I mean shutting down automatically.
Current project:
Nope.
Nope.
Is there any useful info in stderr.txt?
The H. World levelset can be downloaded from http://www.bd-fans.com/RnD.html -- search The H. World on that page.
Arno Luppold's level set is in Contributions 2000.
I got the same thing when I played the level. However, when it crashed in the editor, that could have been the scrolling bug, where it crashes if you use the arrow keys to scroll.
After the crash, I checked my stderr files. The one in RnD's directory was blank. The one in My Documents had messages mostly about "rocksndiamonds.exe: warning: unknown token(s) found in config file:" and all pointed to my levels/config files.
I got the same thing when I played the level. However, when it crashed in the editor, that could have been the scrolling bug, where it crashes if you use the arrow keys to scroll.
After the crash, I checked my stderr files. The one in RnD's directory was blank. The one in My Documents had messages mostly about "rocksndiamonds.exe: warning: unknown token(s) found in config file:" and all pointed to my levels/config files.
Strange indeed.
The bug with the editor in this level seems to be the scrolling bug, I just tested with rnd-20071031 and it work fine in the editor.
While playing however, it did not work. At first when I saw this thread I thought that it could be because an unknown element, so I loaded up RnD Scripter with the "countels" script and got this:
(Element, Count): 0, 1, 117
(Element, Count): 1, 2, 7
(Element, Count): 2, 12, 222
(Element, Count): 3, 13, 306
(Element, Count): 4, 19, 15438
(Element, Count): 5, 28, 286
(Element, Count): 6, 33, 1
(Element, Count): 7, 37, 1
(Element, Count): 8, 44, 4
(Element, Count): 9, 80, 1
(Element, Count): 10, 107, 1
This means that the level contains 11 different kinds of elements, which are the following:
x117
x7
x222
x306
x15438
x286
x1
x1
x4
x1
x1
But I find neither of these to be buggy in any other level, so I have no clue.
Anyone who can find an old RnD version where this level works fine? That maybe could give us a clue...
The bug with the editor in this level seems to be the scrolling bug, I just tested with rnd-20071031 and it work fine in the editor.
While playing however, it did not work. At first when I saw this thread I thought that it could be because an unknown element, so I loaded up RnD Scripter with the "countels" script and got this:
(Element, Count): 0, 1, 117
(Element, Count): 1, 2, 7
(Element, Count): 2, 12, 222
(Element, Count): 3, 13, 306
(Element, Count): 4, 19, 15438
(Element, Count): 5, 28, 286
(Element, Count): 6, 33, 1
(Element, Count): 7, 37, 1
(Element, Count): 8, 44, 4
(Element, Count): 9, 80, 1
(Element, Count): 10, 107, 1
This means that the level contains 11 different kinds of elements, which are the following:











But I find neither of these to be buggy in any other level, so I have no clue.
Anyone who can find an old RnD version where this level works fine? That maybe could give us a clue...
-
- Posts: 366
- Joined: Sun Sep 25, 2005 4:41 pm
- Location: Germany
-
- Posts: 366
- Joined: Sun Sep 25, 2005 4:41 pm
- Location: Germany
OK, I've just found and fixed this nasty crash bug! :-)
Will be released together with the next stable release (or maybe earlier with a new pre-release).
> may be it have something to do with the "request" (SDL) bug
> I mentioned in my mail?
No, it was an invalid memory access in src/game.c in function
UpdateGameControlValues() (in the very last "for" loop), where "gpc->value" could have been -1. Interpreting this as an element number, used as an array index, caused an invalid memory access in rare conditions (when there was no own memory at that place just by chance). Adding a "if (gpc->value != EL_UNDEFINED)" just after "if (gpc->type == TYPE_ELEMENT)" fixes this problem.
> In RNDTEST it don't crash!
This is most probably because there is always valid memory (allocated by the same process) at that location in rndTest, most probably due to your changes to R'n'D which, just by chance, allocate enough additional memory at the "right" position to prevent the segmentation violation.
Sometimes unmanaged code (like compiled C code) really sucks... :-(
Will be released together with the next stable release (or maybe earlier with a new pre-release).
> may be it have something to do with the "request" (SDL) bug
> I mentioned in my mail?
No, it was an invalid memory access in src/game.c in function
UpdateGameControlValues() (in the very last "for" loop), where "gpc->value" could have been -1. Interpreting this as an element number, used as an array index, caused an invalid memory access in rare conditions (when there was no own memory at that place just by chance). Adding a "if (gpc->value != EL_UNDEFINED)" just after "if (gpc->type == TYPE_ELEMENT)" fixes this problem.
> In RNDTEST it don't crash!
This is most probably because there is always valid memory (allocated by the same process) at that location in rndTest, most probably due to your changes to R'n'D which, just by chance, allocate enough additional memory at the "right" position to prevent the segmentation violation.
Sometimes unmanaged code (like compiled C code) really sucks... :-(
-
- Posts: 366
- Joined: Sun Sep 25, 2005 4:41 pm
- Location: Germany
if you remember correctly this is fixed in rndTest too.No, it was an invalid memory access in src/game.c in function
UpdateGameControlValues() (in the very last "for" loop), where "gpc->value" could have been -1. Interpreting this as an element number, used as an array index, caused an invalid memory access in rare conditions (when there was no own memory at that place just by chance). Adding a "if (gpc->value != EL_UNDEFINED)" just after "if (gpc->type == TYPE_ELEMENT)" fixes this problem.
we discuss this in the mail (about too much checking of values)
HeHe do you remember?
Only don't think that this have something to do with this bug.
And the answer is ... 42 !
> if you remember correctly this is fixed in rndTest too.
> we discuss this in the mail (about too much checking of values)
> HeHe do you remember?
Yes, now I remember again! Oh well! :-o
I was 100% sure that "gpc->value" could not legally get "-1" at that part of the code (other by memory getting overwritten by other errors), therefore having no need to check this, but in fact it can! :-O
This was due to later additions, where EL_UNDEFINED (which is in fact "-1") was used to mark panel elements as "not used / not displayed".
But in fact you were right after all that this case could happen, even under "legal" circumstances! :-o :-)
> we discuss this in the mail (about too much checking of values)
> HeHe do you remember?
Yes, now I remember again! Oh well! :-o
I was 100% sure that "gpc->value" could not legally get "-1" at that part of the code (other by memory getting overwritten by other errors), therefore having no need to check this, but in fact it can! :-O
This was due to later additions, where EL_UNDEFINED (which is in fact "-1") was used to mark panel elements as "not used / not displayed".
But in fact you were right after all that this case could happen, even under "legal" circumstances! :-o :-)
This should be fixed in the next stable release, but also in the current pre-release:
http://www.artsoft.org/RELEASES/win32/r ... 080122.zip
(You also need the other pre-releases between the current stable release and this last pre-release. If you don't know how to get it to work, just wait for the next "official", stable release, which won't need special tweaking.)
http://www.artsoft.org/RELEASES/win32/r ... 080122.zip
(You also need the other pre-releases between the current stable release and this last pre-release. If you don't know how to get it to work, just wait for the next "official", stable release, which won't need special tweaking.)