Reading of ogg file stalls on i386

[rlaboiss]

The latest version of Praat (4.1.42) for Debian is not building correctly on the i386 architecture. The package compilation run into a hanging state when exercising the unit test test_readAudioFiles.praat (full log).

It seems that the script gets stuck at the command vorbis = Read from file: "Example_vorbis_audio.ogg" (it does succeed to read the Opus file, though).

Any suggestion on how to debug this problem?

[PaulBoersma]

This must occur in dwtools/Sound_readFromOggVorbisFile.cpp. I do see "while (true)" in that code, and the only break from the loop occurs when ogg_stream_packetout returns 0. Is it possible for ogg_stream_packetout to always return something unequal to 0? That would explain a hang. There are also two instances of "while (! eos)", and these could hang if ogg_page_eos keeps on returning 0. These facts suggest where one could look for the results of these OGG functions, to see which of the two refuses to yield 0 (for ogg_stream_packetout) or not 0 (for ogg_page_eos).

[rlaboiss]

I think that I will disable the running of the unit test test_readAudioFiles.praat in the Debian package building for now. I do not have time for debugging this problem on i386. Moreover, the i386 architecture will eventually be dropped from Debian at some point…

[PaulBoersma]

I tried to start debugging Praat for i386 Linux today, but it turned out that my 32-bit Ubuntu Mate could no longer start up with the current version of Parallels Desktop. Consider that dropped.

On my 32-bit Raspberry PI, the script gives an interesting error, namely "Error: Input does not appear to be an Ogg Vorbis bitstream." This can well be due to the same bug that caused a crash on your i386, so I will be able to investigate now.

[rlaboiss]

Great, I hope you will be able to find the origin of the bug.

[PaulBoersma]

Yes, found. It is interesting. The bug was in Xiph.org's Vorbis code:

static ov_callbacks OV_CALLBACKS_NOCLOSE = {
    (size_t (*)(void *, size_t, size_t, void *))  fread,
    (int (*)(void *, ogg_int64_t, int))           fseek,
    (int (*)(void *))                             nullptr,
    (long (*)(void *))                            ftell
};

They were casting the function fseek, which on 32-bit platforms usually takes a 32-bit second parameter (the file position to jump to) to a function that takes a 64-bit second parameter. Yes, that's undefined behaviour. The trick that Xiph.org performs here, achieves the opposite of what it is intended to do.

Turning fseek into fseeko turns out to prevent the error that I mentioned on the Raspberry Pi. You may try whether that also solves your crash on i386 Linux.

[rlaboiss]

I am impressed that you could nail down this bug. This is an upstream issue and should be reported to the upstream authors of Vorbis. Are you planning to do it? (I know that you decided to keep a copy of the Vorbis sources in the Praat sources, so that you do not need to wait for upstream fixes to have them propagated to Praat.)

[rlaboiss]

I released a new version of the Debian package for Praat (6.1.51.-3), that includes the relevant part of your commit c80187c. The package built correctly on i368 (the unit test test_readAudioFiles.praat succeeded).

I am hereby closing this issue.