TADS Bug Database

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000229TADS 3Compilerpublic2014-08-16 06:522015-08-06 02:05
ReporterEric Eve 
Assigned ToMichael Roberts 
PrioritynormalSeveritycrashReproducibilityalways
StatusresolvedResolutionfixed 
PlatformDell PCOSWindows 7OS Version
Summary0000229: String splice method corrupts and crashes with non-ASCII characters
DescriptionIf the splice() method of String is used to make changes to a string that involve replacing and/or inserting a character beyond the 7-bit ASCII range, the string that is returned is corrupted (with an additional spurious character at the end) and, after enough repeats (the number required seems to be random) Workbench crashes.
Steps To ReproduceTry the following game code:

gameMain: GameMainDef
     initialPlayerChar = me
;

startroom: Room 'The Startroom'
    "<<doStuff('\u00F6')>>."
;

+ me: Actor
;

doStuff(txt)
{
    local str = 'The ' + txt;

    local paramLen = txt.length;
    local sub = txt;
    
    str = str.splice(5, paramLen, sub);

    return str;
}

Keep entering LOOK commands. At first you'll simply see spurious characters appear after the o-umlaut character. Eventually (after a random number of turns) Workbench will crash.
Additional InformationMy best guess is that the splice() method is overwriting some area of memory it shouldn't when it handles characters beyond the 7-bit ASCII range.
TagsNo tags attached.
Fixed In Version3.1.4
Attached Files

- Relationships

-  Notes
(0000404)
Michael Roberts (administrator)
2015-08-06 02:05

Fixed for the next update. (Your guess about the underlying cause is close. The actual problem had to do with calculating the length of the return string. There wasn't actually any scribbling out of bounds; kind of the opposite. The result string had its length set too long when multibyte characters were in the deleted section, so there were uninitialized bytes at the end of the string. The crashes happened when the random trailing bytes weren't well-formed UTF-8 sequences and whatever code was looking at them got misaligned in a loop as a result - in unlucky cases this would make subsequent scans miss a loop termination condition and go off on wild chases into invalid memory regions, triggering CPU memory exceptions and terminating the process.)

- Issue History
Date Modified Username Field Change
2014-08-16 06:52 Eric Eve New Issue
2015-08-06 02:05 Michael Roberts Fixed In Version => 3.1.4
2015-08-06 02:05 Michael Roberts Note Added: 0000404
2015-08-06 02:05 Michael Roberts Assigned To => Michael Roberts
2015-08-06 02:05 Michael Roberts Status new => resolved
2015-08-06 02:05 Michael Roberts Resolution open => fixed


Copyright © 2000 - 2017 MantisBT Team
Powered by Mantis Bugtracker