Date   

Updates to Github #github

espeak-ng@groups.io Integration <espeak-ng@...>
 

[espeak-ng:master] New Comment on Issue #912 GPLv3 license violation
By valdisvi:

This site of Speak NG project is used for collaboration of eSpeak NG users and developers. It is not meant neither for court nor police. If mentioned software violates license, you can report it in https://gpl-violations.org/ or https://www.gnu.org/licenses/gpl-violation.html, or similar place. Also note, that the most eager ones, who look that somebody do something illegal, are competitors.


[espeak-ng:master] New Comment on Issue #912 GPLv3 license violation
By valdisvi:

This site of Speak NG project is used for collaboration of eSpeak NG users and developers. It is not meant neither for court nor police. If mentioned software violates license, you can report it in https://gpl-violations.org/ or https://www.gnu.org/licenses/gpl-violation.html, or similar place. Also note, that the most eager ones, who look that somebody is doing something illegal, are competitors.


[espeak-ng:master] reported: The change to tests/translate.test to detect #824 causes unexplained failures on some builds #github

espeak-ng@groups.io Integration <espeak-ng@...>
 

[espeak-ng:master] New Comment on Issue #945 The change to tests/translate.test to detect #824 causes unexplained failures on some builds
By rhdunn:

The word buffer size and phoneme list being of comparable size (800 for the source size and 1000 for the phoneme list size) is predicated on the assumption that the number of phonemes will never be longer than the number of characters. This only really works if the word doesn't contain a lot of numbers or emoji that significantly increase the phoneme count compared to the word/character count.

Some things we could do: 1. Change the word splitting/detection algorithm to handle this case better -- e.g. when a - is followed by a number. 2. Flush the phonemes upto the previous word (so it is still affected by the next word) when it reaches a threshold (e.g. within 100 of the last phonemes) -- that is, set the word separator ph value to null (end of phonemes); call Generate(); copy the remaining phonemes (including the space) to the start of the phoneme list. 3. Make phoneme_list a circular buffer -- this would allow us to avoid the copying to shift the phonemes to the start of the list -- it would be worth doing a performance check on the result to see if this doesn't adversely affect performance. 4. Make phoneme_list a dynamic array (malloc/calloc, using realloc/reallocarray to resize, where on failure (e.g. ENOMEM) the original buffer should be unchanged and an espeak errno error should be returned from the API call). -- this should be conditional to support memory-constrained devices like riscos, and enabled when compiling for one of those platforms.

I would start by creating an API around the phoneme list -- e.g. phoneme_list_add, phoneme_list_current, phoneme_list_get, phoneme_list_next, etc. (which should be added based on how the phoneme_list is used) -- That way, we can add guards and/or change it to a circular/dynamic buffer more easily.


[espeak-ng:master] reported: Temporary fix for issue #945 #github

espeak-ng@groups.io Integration <espeak-ng@...>
 

[espeak-ng:master] New Comment on Pull Request #948 Temporary fix for issue #945
By rhdunn:

Aborting is the wrong thing to do here, as it would cause applications like NVDA, Orca, or screen-dispatcher to stop working unexpectedly. That would a) make it hard to know what is going on, b) annoy users of those applications, and c) possibly prevent those users from using the device. Thus, this is just as worse as the crash.


[espeak-ng:master] reported: The change to tests/translate.test to detect #824 causes unexplained failures on some builds #github

espeak-ng@groups.io Integration <espeak-ng@...>
 

[espeak-ng:master] New Comment on Issue #945 The change to tests/translate.test to detect #824 causes unexplained failures on some builds
By jbowler:

I pushed a temporary fix. Please check the pull request.

Verified against 8.4.0; make all (-O0), make check. I've pulled to 11.1.0 and verifed ; fine there too.


Updates to Github #github

espeak-ng@groups.io Integration <espeak-ng@...>
 

[espeak-ng/espeak-ng] Pull request opened by jbowler:

#948 Temporary fix for issue #945

Signed-off-by: John Bowler jbowler@...


[espeak-ng:master] New Comment on Issue #945 The change to tests/translate.test to detect #824 causes unexplained failures on some builds
By jbowler:

I pushed a temporary fix. Please check the pull request.


[espeak-ng:master] New Comment on Issue #945 The change to tests/translate.test to detect #824 causes unexplained failures on some builds
By jbowler:

I pushed a temporary fix. Please check the pull request.

Verified against 8.4.0; make all (-O0), make check. I'll pull to 11.1.0 and verify but that seems slightly irrelevant.


Pull Request Closed #github

espeak-ng@groups.io Integration <espeak-ng@...>
 

[espeak-ng/espeak-ng] Pull request closed by jbowler:

#946 Workround for #945; check for 'ru sum strings'

The change made to 'tests/translate.test' to detect bug #824 also demonstrates what has been described to me as a compiler dependency in the output; on my system every occurence of "a " in the phoneme output is actually output as "a# ".

This is reported in issue #945 (I could find no prior report) however the issue does not seem to be fixed anytime soon; it has been around since the test was added in 30214437fc0bb0d067bb60cd550e192edcd2a626 on Dec. 20, 2020.

The test terminates 'make check' in the case in question and therefore obscures any following errors and makes it very difficult to debug unrelated changes to any part of espeak-ng or the build system.

This change adds support for tests/common:test_phon for a MESSAGE argument "ru sum strings" which was added to the test_phon call by 17e6bd0672421467554dcca95f04c2a63b70c510 on the 16th inst. (although that change doesn't seem to do anything).

If "ru sum strings" is passed every occurence of "a# " in the output received from espeak-ng is changed to "a ". Since "a# " does not occur in the correct output this makes no difference to the original check.

Obviously I've only tested this on my system, I know the issue is known but since there did not seem to be a bug report until I entered #945 I don't know what output other systems generate (other than the correct output). The change is intended to allow "make check" to skip this known error and therefore detect other issues.

Signed-off-by: John Bowler jbowler@...


Updates to Github #github

espeak-ng@groups.io Integration <espeak-ng@...>
 

[espeak-ng:master] New Comment on Issue #945 The change to tests/translate.test to detect #824 causes unexplained failures on some builds
By jbowler:

Add this line after the declaration of n_ph_list2 in translate.c to stop malware:

#define n_ph_list2 (*(n_ph_list2 > N_PHONEME_LIST ? abort(),0 : &n_ph_list2))

I think even a function call to a meaningful error message would be safe at that point too, in practice, but abort() or _exit() are certain to be safe.


[espeak-ng:master] New Comment on Issue #945 The change to tests/translate.test to detect #824 causes unexplained failures on some builds
By jbowler:

Add this line after the declaration of n_ph_list2 in translate.c to stop malware:

#define n_ph_list2 (*(n_ph_list2 > N_PHONEME_LIST ? abort(),0 : &n_ph_list2))

I think even a function call to a meaningful error message would be safe at that point too, in practice, but abort() or _exit() are certain to be safe.

With those two changes (though I think the first is irrelevant; the #define is what counts) "make check" passes with gcc 11.1.0 if I message the relevant test_phon ru line as "broken" and 'ignore' the ssml audio checksum mismatch. So this can be done safely without annoying other developers.


[espeak-ng:master] reported: The change to tests/translate.test to detect #824 causes unexplained failures on some builds #github

espeak-ng@groups.io Integration <espeak-ng@...>
 

[espeak-ng:master] New Comment on Issue #945 The change to tests/translate.test to detect #824 causes unexplained failures on some builds
By jbowler:

The attached patch does not protect against malware (crackers) but it should detect the overwrite with moderate to good reliability. translate.c.patch.txt

Some manner of malware protection could be achieved using a random byte for ucheck, though not much because the damage would already be done...


[espeak-ng:master] reported: The change to tests/translate.test to detect #824 causes unexplained failures on some builds #github

espeak-ng@groups.io Integration <espeak-ng@...>
 

[espeak-ng:master] New Comment on Issue #945 The change to tests/translate.test to detect #824 causes unexplained failures on some builds
By jbowler:

It seems to have happening because of all the Latin "C" characters; they switch the phoneme table. There are checks in TranslateWord2 for overflow of ph_list2 in some places but not all. Places that do check check for space for four phonemes, but when the space runs out the code just drops through to more code that assumes there is space for four more phonemes. I suspect the "expected.txt" is actually heavily truncated as a result - there's no proper error recovery if the buffer space runs out, the code just keeps on skipping some phonemes and writing others.


Updates to Github #github

espeak-ng@groups.io Integration <espeak-ng@...>
 

[espeak-ng:master] New Comment on Issue #945 The change to tests/translate.test to detect #824 causes unexplained failures on some builds
By jbowler:

Here's the debug approach with 8.4.0 compiled -O0, starting with a breakpoint on TranslateClause:

(gdb) run -xq -v ru -f /tmp/fragment.txt
Starting program: /home/jbowler/src/espeak-ng/install-8.4.0-debug/bin/espeak-ng -xq -v ru -f /tmp/fragment.txt
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7ffff74bc640 (LWP 2248)]

Thread 1 "espeak-ng" hit Breakpoint 1, TranslateClause (tr=0x555555594810, 
    tone_out=0x7fffffffd2b4, voice_change=0x7fffffffd2b8)
    at src/libespeak-ng/translate.c:1985
1985    {
(gdb) watch ((char*)&count_words)[2]
Hardware watchpoint 4: ((char*)&count_words)[2]
(gdb) c
Continuing.

Thread 1 "espeak-ng" hit Hardware watchpoint 4: ((char*)&count_words)[2]

Old value = 0 '\000'
New value = 21 '\025'
SetPlist2 (p=0x7ffff7fbe820 <count_words>, phcode=21 '\025')
    at src/libespeak-ng/translate.c:1226
1226            p->stresslevel = 0;
(gdb) print /x count_words
$6 = 0x15006a
(gdb) next
1227            p->tone_ph = 0;
(gdb) print /x count_words
$7 = 0x15006a
(gdb) next
1228            p->synthflags = embedded_flag;
(gdb) print /x count_words
$8 = 0x15006a
(gdb) next
1229            p->sourceix = 0;
(gdb) print /x count_words
$9 = 0x150000
(gdb) next
1230            embedded_flag = 0;
(gdb) print /x count_words
$10 = 0x150000
(gdb) next
1231    }
(gdb) print /x count_words
$11 = 0x150000


[espeak-ng:master] New Comment on Issue #945 The change to tests/translate.test to detect #824 causes unexplained failures on some builds
By rhdunn:

Great! Thanks for doing the investigation. I agree that a# should be the correct phoneme in the output.


[espeak-ng:master] reported: The change to tests/translate.test to detect #824 causes unexplained failures on some builds #github

espeak-ng@groups.io Integration <espeak-ng@...>
 

[espeak-ng:master] New Comment on Issue #945 The change to tests/translate.test to detect #824 causes unexplained failures on some builds
By jbowler:

The problem is a write-beyond-end of ph_list2. This contains 1000 elements and with both 8.4.0 and 11.1.0 the code seems to write beyond the end. The difference is that the list is followed by the global count_words in 8.4.0 whereas in 11.1.0 it is followed by option_punctlist. There does seem to be code to truncate the processing; the string in question is generating many more phonemes than there are characters/bytes in the input, but it doesn't seem to be quite correct. With 8.4.0 the overwrite extends into the 'replace_phonemes' global, with 11.1.0 it stops before that.

Here are copies of two sets of debug output obtained at a breakpoint on SubstitutePhonemes, first with 11.1.0 (which, I believe, is producing the correct output despite the overwrite):

(gdb) run -xq -v ru -f 
[fragment.txt](https://github.com/espeak-ng/espeak-ng/files/6528761/fragment.txt)

Starting program: /home/jbowler/src/espeak-ng/install/bin/espeak-ng -xq -v ru -f /tmp/fragment.txt
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7ffff74bb640 (LWP 13887)]

Thread 1 "espeak-ng" hit Breakpoint 1, SubstitutePhonemes (
    plist_out=0x7fffffff1b00) at src/libespeak-ng/phonemelist.c:56
56              int n_plist_out = 0;
(gdb) print n_ph_list2
$33 = 998
(gdb) print ph_list2[1000]
$34 = {synthflags = 0, phcode = 21 '\025', stresslevel = 0 '\000', 
  sourceix = 0, wordstress = 0 '\000', tone_ph = 11 '\v'}
(gdb) print ph_list2+1000
$35 = (PHONEME_LIST2 *) 0x7ffff7fba3e0 <option_punctlist>
(gdb) print option_punctlist
$36 = L"\x150000\xb000000\x150000\xb000000\x150000\xb000000\x150000\xb000000\x150000\xb000000\x150000\xb000000\x150000\xb000000\x150000\xb000000\x150000\xb000000\x150000\xb000000\x150000\xb000000\x150000\xb000000\x150000\xb000000\x150000\xb000000\x150000\x2b000000\x90000˞\x90000˞", '\000' <repeats 25 times>
(gdb) print count_words
$37 = 232

With 8.4.0, however, we can see that "option_punctlist" should be all zero (uninitialized/unwritten) but that count_words has been damaged:

(gdb) run -xq -v ru -f /tmp/fragment.txt
Starting program: /home/jbowler/src/espeak-ng/install-8.4.0-debug/bin/espeak-ng -xq -v ru -f /tmp/fragment.txt
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7ffff74bc640 (LWP 13879)]

Thread 1 "espeak-ng" hit Breakpoint 1, SubstitutePhonemes (
    plist_out=0x7fffffff1ac0) at src/libespeak-ng/phonemelist.c:56
56              int n_plist_out = 0;
(gdb) print n_ph_list2
$67 = 1000
(gdb) print ph_list2[1000]
$68 = {synthflags = 126, phcode = 21 '\025', stresslevel = 0 '\000', 
  sourceix = 0, wordstress = 0 '\000', tone_ph = 11 '\v'}
(gdb) print ph_list2+1000
$69 = (PHONEME_LIST2 *) 0x7ffff7fbe820 <count_words>
(gdb) print option_punctlist
$70 = L'\000' <repeats 59 times>
(gdb) print count_words
$71 = 1376382
(gdb) print /x count_words
$72 = 0x15007e

I experimented with English and a file which has 314 bytes (though slightly fewer characters) which expand to slightly more than 998 phonemes; equation.txt. It does not show the problem; both builds truncate the output at 998 phonemes. Likewise if I translate that file into Russian ru-eq.txt (Google Translate) except that in that case the output isn't truncated, it is split.

I increase N_PHONEME_LIST to 10000, which avoids the need to split the string, and got fragment.out.txt; I'm pretty sure this is the correct string however in scenarios where the bug might show the string should be split into two TranslateClause outputs (they are separated by new line).

Anyway, without the increase, the first overwrite is at line 1226 of translate.c inside SetPlist2

(gdb) print p
$12 = (PHONEME_LIST2 *) 0x7ffff7fba3e0 <option_punctlist>

Someone who understands how the truncation/splitting of overlong input is meant to work probably needs to look at it now. It's easy to trap on more recent gcc's because option_punctlist is not actually modified, so a simple "watch" catches the problem (and it's a hardware watch, so it is fast). Catching it with 8.x or earlier is more of a problem since word-count changes; I'll see if I can trap it with (char*)word_count+2 (since word_count shouldn't go over 65535).


[espeak-ng:master] reported: Workround for #945; check for 'ru sum strings' #github

espeak-ng@groups.io Integration <espeak-ng@...>
 

[espeak-ng:master] New Comment on Pull Request #946 Workround for #945; check for 'ru sum strings'
By jbowler:

Well, indeed; the test really is detecting a memory overwrite (see #945) but it is using the wrong output string; the one my build produces might be the correct one. @jaacoppi didn't like disabling it (this was my first approach too) because it is meant to detect a crash. It's probably best to disable it at present because until the overwrite is fixed the correct answer is unknown...


[espeak-ng:master] reported: The change to tests/translate.test to detect #824 causes unexplained failures on some builds #github

espeak-ng@groups.io Integration <espeak-ng@...>
 

[espeak-ng:master] New Comment on Issue #945 The change to tests/translate.test to detect #824 causes unexplained failures on some builds
By jbowler:

In 8.4.0 a breakpoint at SubstitutePhonemes shows that replace_phonemes[0] is badly formed. Here's the 11.1.0 version which does the substitute of a -> a#;

(gdb) print replace_phonemes[0]
$2 = {old_ph = 35 '#', new_ph = 136 '\210', type = 3 '\003'}

35 is the phcode of the Russian a phoneme and all the fields seem valid to me. Here is what 8.4.0 has (BTW, this behavior is visible in -O0, so it's unlikely to be an optimization issue):

(gdb) print replace_phonemes[0]
$2 = {old_ph = 32 ' ', new_ph = 0 '\000', type = 21 '\025'}

n_replace_phonemes is still 1. I'm guessing this is a memory overwrite; what gets overwritten often depends on the compiler. replace_phonemes is a global (translate.c/phonemes.h) so a memory overwrite (if that is what it is) is not as bad as a stack overwrite and it shouldn't be hard to track down the preceding structure so check.

A quick check shows that replace_phonemes with 11.1.0 is uninitialized (all zero) apart from the first element, whereas replace_phonemes with 8.4.0 has been written to up to the 10th element:

(gdb) print /x *(int*)&replace_phonemes[0].old_ph@32
$37 = {0x150020, 0xb000000, 0x150020, 0xb000000, 0x150020, 0x2b000000, 0x90000, 
  0x229, 0x90000, 0x229, 0x0 <repeats 22 times>}


[espeak-ng:master] reported: The change to tests/translate.test to detect #824 causes unexplained failures on some builds #github

espeak-ng@groups.io Integration <espeak-ng@...>
 

[espeak-ng:master] New Comment on Issue #945 The change to tests/translate.test to detect #824 causes unexplained failures on some builds
By jbowler:

In 8.4.0 a breakpoint at SubstitutePhonemes shows that replace_phonemes[0] is badly formed. Here's the 11.1.0 version which does the substitute of a -> a#;

(gdb) print replace_phonemes[0]
$2 = {old_ph = 35 '#', new_ph = 136 '\210', type = 3 '\003'}

35 is the phcode of the Russian a phoneme and all the fields seem valid to me. Here is what 8.4.0 has (BTW, this behavior is visible in -O0, so it's unlikely to be an optimization issue):

(gdb) print replace_phonemes[0]
$2 = {old_ph = 32 ' ', new_ph = 0 '\000', type = 21 '\025'}

n_replace_phonemes is still 1. I'm guessing this is a memory overwrite; what gets overwritten often depends on the compiler. replace_phonemes is a global (translate.c/phonemes.h) so a memory overwrite (if that is what it is) is not as bad as a stack overwrite and it shouldn't be hard to track down the preceding structure so check.


[espeak-ng:master] reported: Workround for #945; check for 'ru sum strings' #github

espeak-ng@groups.io Integration <espeak-ng@...>
 

[espeak-ng:master] New Comment on Pull Request #946 Workround for #945; check for 'ru sum strings'
By valdisvi:

@jbowler, this workaround is too specific. @rhdunn already implemented way to ignore some tests with "broken" message (4th parameter) in some tests. I added this for all other functions and renamed it to more conventional "Ignore" message.: 40b78f5183f66958b333d8a54f0ab25a9576be5e so can adjust some of failing tests locally on your environment.


Github push to espeak-ng:espeak-ng #github

espeak-ng@groups.io Integration <espeak-ng@...>
 

1 New Commit:

[espeak-ng:master] By Valdis Vitolins <valdis.vitolins@...>:
40b78f5183f6: Add handling of Ignore message for all test functions

Modified: tests/common


[espeak-ng:master] reported: The change to tests/translate.test to detect #824 causes unexplained failures on some builds #github

espeak-ng@groups.io Integration <espeak-ng@...>
 

[espeak-ng:master] New Comment on Issue #945 The change to tests/translate.test to detect #824 causes unexplained failures on some builds
By jbowler:

And, indeed; I did a "make install" (to install-8.4.0, as configured) and ran bin/espeak-ng; the test script has the missing '#' characters, the simplified test does not. Swapping to my HEAD test install shows the other behavior; the only change is that my HEAD contains 88c4a452fe40413a146d21e31856fcfa9e7e4eea but it's difficult to believe that this (addition of a sed command in the test) would make a difference to the behavior of an installed espeak-ng...


[espeak-ng:master] reported: The change to tests/translate.test to detect #824 causes unexplained failures on some builds #github

espeak-ng@groups.io Integration <espeak-ng@...>
 

[espeak-ng:master] New Comment on Issue #945 The change to tests/translate.test to detect #824 causes unexplained failures on some builds
By jbowler:

Ok, with this configure:

CC=gcc-8.4.0 ./configure --prefix=$HOME/src/espeak-ng/install-8.4.0

and this clone:

~/src/espeak-ng/git-8.4.0 $ git status
HEAD detached at f6d092a9
nothing to commit, working tree clean

I get this:

configure:

    Configuration for eSpeak NG complete.

        Source code location:          .

        C99 Compiler:                  gcc-8.4.0
        C99 Compiler flags:            -Wunused-parameter -Wunused -Wuninitialized -Wreturn-type -Wmissing-prototypes -Wimplicit -g -O2 -std=c99

        Sonic:                         no
        PCAudioLib:                    no

        gradle (Android):              gradle
        ndk-build (Android):           

        Klatt:                         yes
        speechPlayer:                  yes
        MBROLA:                        yes
        Async:                         yes

        Extended Dictionaries:
            Russian:                   no
            Chinese (Mandarin):        no
            Chinese (Cantonese):       no

And then "make check" produces the attached log file, which repros your 8.3.0 set; i.e. testing ru ru sum strings passes. So that gives me something to debug :-) make-check.log


[espeak-ng:master] reported: The change to tests/translate.test to detect #824 causes unexplained failures on some builds #github

espeak-ng@groups.io Integration <espeak-ng@...>
 

[espeak-ng:master] New Comment on Issue #945 The change to tests/translate.test to detect #824 causes unexplained failures on some builds
By jbowler:

Sorry; the compiler/OS info was in #947:

  • gcc (Gentoo 11.1.0 p1) 11.1.0
  • Linux hippopopus 5.12.5-gentoo #1 SMP Thu May 20 09:29:16 PDT 2021 x86_64 Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz GenuineIntel GNU/Linux
  • The OS is Gentoo running the KDE Plasma 17.1 desktop profile: /usr/portage/profiles/default/linux/amd64/17.1/desktop/plasma
  • The audio is: AUDIO_USE="jack pulseaudio openal"

I've got 8.4.0 of gcc installed now, but haven't tried that yet.


[espeak-ng:master] reported: The change to tests/translate.test to detect #824 causes unexplained failures on some builds #github

espeak-ng@groups.io Integration <espeak-ng@...>
 

[espeak-ng:master] New Comment on Issue #945 The change to tests/translate.test to detect #824 causes unexplained failures on some builds
By rhdunn:

I was wrong w.r.t. the reading of fractions. The _. entry is for pronouncing the . character. The _dpt and _dpt2 are for the start and end of the decimal fraction.

The point of this test is not to test the number handling (that would be in tests/language-numbers-(cardinal|ordinal).test). The point of translate.test is to check the TranslateClause and related functions (including to some part ReadClause).

BTW this happens with -O0 too, so it doesn't look likely to be either an out-of-bounds or uninitialized memory issue or, for that matter, a compiler issue.

If it is neither a compiler issue nor undefined behaviour (out-of-bounds, etc.), I would expect espeak-ng to use a# on all systems when given the same input. Specifically, why does my system produce a# in 0.8 but not in the test case, whereas yours produces a# on both? -- That is clearly indicating that something is different.

The only way -- per your analysis -- for the test input text is that word_end is true on your machine and false on my machine and the Travis builds. Note: I fixed a bug in a different project that only caused test errors on i386 build machines -- the issue there turned out to be it reading the character after the data string which, when it was a certain character, was causing some logic in the application to be run resulting in different output.

The espeak data such as the word being read and sourceix are arrays stored on the stack -- this is done to keep the application compact on constrained memory devices. If later versions of gcc and clang have changed the stack layout, or add out-of-bounds write sentinels, that could affect what espeak-ng sees when processing the long string (and not when processing shorter strings), and thus the difference in output as noted in the test.

This all indicates that -- again per your analysis -- that it should be outputting a#. What is not clear -- and is what we are trying to isolate and identify -- is why that is not happening on the systems running the tests.

My clangs only run back to clang-10 and gccs to gcc-6.5.0 (which, for some reason, is masked by Gentoo). I do have 8.4.0 - that's actually the earliest unmasked version I have.

You haven't said which compiler and version you are using. If we know that, we can try that compiler/version on our machines to see if we can reproduce the issue.

It seems to me a better way to test not crashing on garbage input would be to just generate a random byte stream, but it should really be covered by the fuzzer tests.

The point of things like generating random byte streams or using fuzzers is to identify new bugs. Once you have identified a bug with a fuzzer, you should add that as a test case to your application, to prevent that bug occurring again.

As has been said, this bug was identified as a crash from a user using NVDA (#824). As such -- in order to prevent a regression -- this has been added to the tests.

601 - 620 of 4790