Assertion failure on linux

[jeremysalwen]

I a getting an assertion failure when running in debug mode on linux:

Assert Failed: l_current_time + m_loop_step < (int)m_channel->get_pitch_lookup_smoothed().size() in ../tartini/sound/notedata.cpp line 117.

I added some debug printing, here is the log:

lookup=1
lookup=2
lookup=3
lookup=4
lookup=5
lookup=6
lookup=7
lookup=8
lookup=9
lookup=10
lookup=11
lookup=12
lookup=13
lookup=14
lookup=15
lookup=16
lookup=17
lookup=18
lookup=19
lookup=20
lookup=21
lookup=22
lookup=23
lookup=24
lookup=25
lookup=26
lookup=27
lookup=28
lookup=29
lookup=30
lookup=31
lookup=32
lookup=33
lookup=34
lookup=35
lookup=36
lookup=37
lookup=38
lookup=39
lookup=40
lookup=41
lookup=42
lookup=43
lookup=44
lookup=45
lookup=46
lookup=47
NoteData Constructor m_loop_start=1516 m_start_chunk=46 framesPerChunk()=32 m_loop_step=44
lookup=48
lookup=49
lookup=50
lookup=51
Before Assertion m_loop_start=1516 current_time=1516 loop_step=44 pitch_lookup_size=816
Assert Failed: l_current_time + m_loop_step < (int)m_channel->get_pitch_lookup_smoothed().size() in ../tartini/sound/notedata.cpp line 117.

(lookup= is an existing printf from channel.cpp)

This error doesn't occur in the original tartini. I added similar printf statements, and I got

NoteData Constructor m_loop_start=2092 m_start_chunk=2 framesPerChunk()=32 loop_step=44
Before Assertion m_loop_start=2092 current_time=2092 loop_step=44 pitch_lookup_size=3072

Do you have any idea where you might have introduced this bug?

[quicky2000]

Hello @jeremysalwen

In fact if I remember well when we tried to use original Tartini on Linux we sometimes faced some crash.
By investigating around that we found that the reason was an out of bound access that was caused by l_current_time + m_loop_step greater than size of vector pitch_lookup_smoothed.
At this time the bug is still not solved but we add an assert to detect such out of bound access in order to debug it.
This is exactly what occur for you.
With original tartini the check is not there so out of bounds access are performed and if you are lucky there is no crash but the bug is there.
We didn't introduced the bug, we added a systematic symptoma of the bug but for sure we need to understand the bug in order to correct it
Is it more clear ?

[jeremysalwen]

Hmm, I think this is a different check than the one you are thinking of. The check was present in the original tartini source: https://github.com/jeremysalwen/tartini-debian/blob/master/sound/notedata.cpp#L124

You can also see from the debug data I output above that the constraint is satisfied in the original version.

[quicky2000]

yes you are right, i was confused with some other asserts we add.
Normally I didn't modify Tartini algorithm, perhaps I missed something.
How do you proceed to use the same data on both old version and mine one ?
you have an audio file that you could share so I can try to locate the issue ?

[jeremysalwen]

I see it almost immediately when recording any audio. So the data is not exactly the same, but it's highly reproducible.

[quicky2000]

ok. on which commit are you exactly ? the location of assert is not the one I observe in my latest commit.

[jeremysalwen]

I think the only difference is some added print (moving it down a couple lines). I uploaded my exact version to https://github.com/jeremysalwen/tartini

[quicky2000]

Hello. Could you give more details on your configuration: Qt, Qwt versions ? compiler used etc ?
On my side with g++ 7.4.0 , Qt 5.9.5, Qwt 6.1.3 on Kubuntu 18.04 I tested several times and I don't succeed to reproduce the issue

[jeremysalwen]

g++ (Debian 8.3.0-6) 8.3.0
qt 5.11.3
qwt 6.1.4-1
on a debian-derived distro.

I think it may be hard for you to reproduce, but if you have any ideas for what the root cause of this change was, I could run any instrucmentation, or debug myself.

[quicky2000]

What you could try is comment line 29 of myassert.h so that condition failure still print the message but don't stop execution.
Run Tartini with its recording function and stop it after several assertion failure display.
Then try to open the resulting wave file with tartini and check if assertion failure message are printed.
if yes you could share the wave file with me and we would be able to compare executions

[quicky2000]

Problem also encountered by @mself on Mac OS.
The good news it that he obtains it with example.wav from Tartini website so it will allow to compare with my own execution that don't crash

I copy/paste the report from @mself

NoteData::addVibratoData:

114: myassert(l_current_time + m_loop_step < (int)m_channel->get_pitch_lookup_smoothed().size());

lldb) p l_current_time
(int) $3 = 1388
(lldb) p m_loop_step
(int) $4 = 44
(lldb) p m_channel->get_pitch_lookup_smoothed().size()
(uint) $5 = 720

Backtrace:

• frame Variable l_string is declared twice in hcirclewidget::paintEvent #3: 0x00000001000ba84e tartiniNoteData::addVibratoData(this=0x00000001107102f8, p_chunk=44) at notedata.cpp:114:13 frame #4: 0x0000000100015877 tartiniChannel::calcVibratoData(this=0x00000001038b54d0, p_chunk=44) at channel.cpp:1197:25
  frame Variable l_n is declared twice in FreqWidgetGL::drawChannelGL #5: 0x0000000100091f7b tartiniMyTransforms::calculateAnalysisData(this=0x00000001038913d0, p_chunk=44, p_channel=0x00000001038b54d0) at mytransforms.cpp:564:24 frame #6: 0x00000001000106cc tartiniSoundFile::calculateAnalysisData(this=0x00000001038913a0, p_chunk=44, p_channel=0x00000001038b54d0) at soundfile.hpp:186:21
  frame Variable l_n is declared twice in FreqWidgetGL::setChannelVerticalView #7: 0x00000001000104e7 tartiniChannel::processNewChunk(this=0x00000001038b54d0, p_filter_state=0x00007ffeefbfca60) at channel.cpp:325:15 frame #8: 0x000000010002b0e5 tartiniSoundFile::readChunk(this=0x00000001038913a0, p_n=32) at soundfile.cpp:529:26
  frame No such signal QwtWheel::sliderMoved(double) #9: 0x000000010002b722 tartini`SoundFile::preProcess(this=0x00000001038913a0) at soundfile.cpp:662:11

This crash only happens when I have "Do detailed pitch analysis" selected in preferences.

[quicky2000]

I created a branch issue_28 to investigated and add a debug message.
@mself could you compile it, open example.wav and attach the log you obtain ?
Here is mine
ok.log.gz