New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nescaline crash when playing very high note #1492

Closed
Moth-Tolias opened this Issue Dec 23, 2014 · 9 comments

Comments

Projects
None yet
5 participants
@Moth-Tolias

Moth-Tolias commented Dec 23, 2014

edit @tref 2014-12-24, added steps to reproduce

Steps to reproduce:

  • Open a blank project
  • Add Nescaline instrument to project
  • Open Nescaline instrument window, set "base note" to far left:

    screen shot 2014-12-24 at 4 04 28 pm
  • Open a new Piano Roll for same instrument
  • Click on the top most note:

    screen shot 2014-12-24 at 4 06 18 pm
  • LMMS crashes:

    screen shot 2014-12-24 at 4 07 19 pm

Found on 64-bit windows (1.1.0, latest release).
The affected presets are:

Chomp
Mega_weapon

Rather bizarrely, duplicating the preset settings did not duplicate the issue. My recreation of Mega_weapon was noticeably louder (this was the only difference I could perceive, however) than the original, so I may have been neglecting some component. I can't think what it might be, though.

EDIT: Just tested 32-bit windows (1.1.0-RC11), and the crash-inducing notes are G8 and above. Affected presets are the same as before. I'll dl 1.1.0 and check whether anything changes.

Edit 2: Just tested 32-bit windows (1.1.0, latest release). Same as before (i.e, notes equal to and greater than G8 crash the program.)

@lukas-w lukas-w added the bug label Dec 24, 2014

@Moth-Tolias

This comment has been minimized.

Show comment
Hide comment
@Moth-Tolias

Moth-Tolias Dec 24, 2014

Apologies for the double post, but I did some file comparisons - the base notes of the reconstructed presets were significantly higher. Reducing it enough leads to crashes, even on the base instrument.

Replication instructions:
-create instance of Nescaline
-set base note to something very low
-play a very high note
-LMMS crashes.

Moth-Tolias commented Dec 24, 2014

Apologies for the double post, but I did some file comparisons - the base notes of the reconstructed presets were significantly higher. Reducing it enough leads to crashes, even on the base instrument.

Replication instructions:
-create instance of Nescaline
-set base note to something very low
-play a very high note
-LMMS crashes.

@Moth-Tolias Moth-Tolias changed the title from Crash when playng very high notes (A9 and above) on certain Nescaline presets to Crash when playng very high notes with low base pitch note in Nescaline instrument Dec 24, 2014

@Moth-Tolias Moth-Tolias changed the title from Crash when playng very high notes with low base pitch note in Nescaline instrument to Crash when playng high notes with low base pitch note in Nescaline instrument Dec 24, 2014

@Moth-Tolias Moth-Tolias changed the title from Crash when playng high notes with low base pitch note in Nescaline instrument to Crash when playing high notes with low base pitch note in Nescaline instrument Dec 24, 2014

@tresf tresf added this to the 1.1.0 milestone Dec 24, 2014

@tresf tresf changed the title from Crash when playing high notes with low base pitch note in Nescaline instrument to Nescaline crash when playing very high note Dec 24, 2014

@tresf

This comment has been minimized.

Show comment
Hide comment
@tresf

tresf Dec 24, 2014

Member

Reproduced per instructions. Thanks. We'll get on this.

Member

tresf commented Dec 24, 2014

Reproduced per instructions. Thanks. We'll get on this.

@mikobuntu

This comment has been minimized.

Show comment
Hide comment
@mikobuntu

mikobuntu Dec 25, 2014

Contributor

confirmed on the linux build .. the 1st debug message is:-

Program received signal SIGFPE, Arithmetic exception.
[Switching to Thread 0xae392b40 (LWP 32515)]
0xac1407a9 in NesObject::renderOutput (this=0xb2064f10, buf=0xb2054c50,
frames=256) at /home/mikobuntu/lmms-stable/lmms/plugins/nes/Nes.cpp:237
237 m_ch1Counter = m_ch1Counter % m_wlen1;

and a full backtrace here ...>>>>> http://paste.ubuntu.com/9615330/

Contributor

mikobuntu commented Dec 25, 2014

confirmed on the linux build .. the 1st debug message is:-

Program received signal SIGFPE, Arithmetic exception.
[Switching to Thread 0xae392b40 (LWP 32515)]
0xac1407a9 in NesObject::renderOutput (this=0xb2064f10, buf=0xb2054c50,
frames=256) at /home/mikobuntu/lmms-stable/lmms/plugins/nes/Nes.cpp:237
237 m_ch1Counter = m_ch1Counter % m_wlen1;

and a full backtrace here ...>>>>> http://paste.ubuntu.com/9615330/

@badosu

This comment has been minimized.

Show comment
Hide comment
@badosu

badosu Dec 26, 2014

Contributor

Confirmed for 9e4db14.

A simple run with gdb revealed the cause is a floating point exception: 0 % 0.

I am not very familiar with sound programming and this plugin, so the meaning of these variables is a little bit cryptic, anyone has more context?

Contributor

badosu commented Dec 26, 2014

Confirmed for 9e4db14.

A simple run with gdb revealed the cause is a floating point exception: 0 % 0.

I am not very familiar with sound programming and this plugin, so the meaning of these variables is a little bit cryptic, anyone has more context?

@tresf

This comment has been minimized.

Show comment
Hide comment
@tresf

tresf Dec 26, 2014

Member

The closest we have to debugging instructions lies here I think...

https://github.com/LMMS/lmms/wiki/Compiling-lmms-(Apple)#debugging-lmms-osx

Obviously you'll have to swap our the Clang command with the classic gdb.

As far as who can fix this... Nes is new w/ 1.1.x and Vesa ("diizy", our most active developer) wrote it... If someone doesn't address it shortly, we can always ping him. :)

Member

tresf commented Dec 26, 2014

The closest we have to debugging instructions lies here I think...

https://github.com/LMMS/lmms/wiki/Compiling-lmms-(Apple)#debugging-lmms-osx

Obviously you'll have to swap our the Clang command with the classic gdb.

As far as who can fix this... Nes is new w/ 1.1.x and Vesa ("diizy", our most active developer) wrote it... If someone doesn't address it shortly, we can always ping him. :)

@badosu

This comment has been minimized.

Show comment
Hide comment
@badosu

badosu Dec 30, 2014

Contributor

Was this fixed by #1529 ? /cc @Moth-Tolias @curlymorphic

Contributor

badosu commented Dec 30, 2014

Was this fixed by #1529 ? /cc @Moth-Tolias @curlymorphic

@tresf

This comment has been minimized.

Show comment
Hide comment
@tresf

tresf Dec 31, 2014

Member

@badosu, doubtful. The stacktrace @mikobuntu posted points to an arithmetic operation on this line: Nes.cpp#L237, likely a divide by zero.

Member

tresf commented Dec 31, 2014

@badosu, doubtful. The stacktrace @mikobuntu posted points to an arithmetic operation on this line: Nes.cpp#L237, likely a divide by zero.

@tresf

This comment has been minimized.

Show comment
Hide comment
@tresf

tresf Dec 31, 2014

Member

So m_wlen1, m_wlen2 and m_wlen3 will all crash the plugin if they're zero. I assume a high enough frequency can round the integer to a zero wavelength, so we should be able to bump them back to 1 if they get too low via:

     if( freq != m_lastNoteFreq )
        {
                m_wlen1 = wavelength( freq * m_parent->m_freq1 );
                m_wlen2 = wavelength( freq * m_parent->m_freq2 );
                m_wlen3 = wavelength( freq * m_parent->m_freq3 );

// ADD THESE PERHAPS

                // sanitize for zero wavelength
                m_wlen1 = ( m_wlen1 == 0 ? 1 : m_wlen1 );
                m_wlen2 = ( m_wlen2 == 0 ? 1 : m_wlen2 );
                m_wlen3 = ( m_wlen3 == 0 ? 1 : m_wlen3 );

        }

It sounds terrible at the higher notes, but it doesn't crash... :)

Member

tresf commented Dec 31, 2014

So m_wlen1, m_wlen2 and m_wlen3 will all crash the plugin if they're zero. I assume a high enough frequency can round the integer to a zero wavelength, so we should be able to bump them back to 1 if they get too low via:

     if( freq != m_lastNoteFreq )
        {
                m_wlen1 = wavelength( freq * m_parent->m_freq1 );
                m_wlen2 = wavelength( freq * m_parent->m_freq2 );
                m_wlen3 = wavelength( freq * m_parent->m_freq3 );

// ADD THESE PERHAPS

                // sanitize for zero wavelength
                m_wlen1 = ( m_wlen1 == 0 ? 1 : m_wlen1 );
                m_wlen2 = ( m_wlen2 == 0 ? 1 : m_wlen2 );
                m_wlen3 = ( m_wlen3 == 0 ? 1 : m_wlen3 );

        }

It sounds terrible at the higher notes, but it doesn't crash... :)

@tresf

This comment has been minimized.

Show comment
Hide comment
@tresf

tresf Jan 15, 2015

Member

Closed via #1601.

Member

tresf commented Jan 15, 2015

Closed via #1601.

@tresf tresf closed this Jan 15, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment