MantisBT

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007422ardourbugspublic2017-07-10 15:192017-08-19 10:57
Reporterrvega 
Assigned Toovenwerks 
PrioritynormalSeveritycrashReproducibilityalways
StatusresolvedResolutionfixed 
Platformx86_64OSManjaro LinuxOS Version17.0.2
Product Version5.X git (version in description) 
Target VersionFixed in Version 
Summary0007422: Ardour crashes when receiving osc messages.
DescriptionI created a new session using JACK as a backend. I am sending the oscsend command line application to trigger playback like: `oscsend osc.udp://localhost:3819 /loop_toggle` when Ardour receives the message, it crashes with a segfault.
See attached stack trace from gdb
TagsNo tags attached.
Attached Filestxt file icon ArdourBacktrace 2.txt [^] (16,040 bytes) 2017-07-10 15:19 [Show Content]

- Relationships

-  Notes
(0019914)
johmue-eo (reporter)
2017-07-20 12:45

Can't reproduce it. Just tested in 5.10-308-g2f6689922.

Does it happen when you send /loop_toggle to a completely empty session?
(0019916)
ovenwerks (reporter)
2017-07-20 16:17

I have tried this with fresh pull from git just now (fresh build dir, fresh configure, build) and it seems to work ok, with or without a loop range in place. I tried with both an old session with audio recorded and with a new session with no new tracks or audio. I have tried with both port mode auto and manual. You say you have been using GIT. There have been many large changes in git in the past few weeks (since 5.10) have you tried anything new from git since this failed? Do you have a session and OSC setup you use?
(0019923)
rvega (reporter)
2017-07-22 13:16

I can't reproduce it with a fresh session. I will upload the session I've been working on that shows this bug on tuesday when I have access to it.
(0019927)
ovenwerks (reporter)
2017-07-24 20:25

rvega: I was able to get Ardour to crash... though not quite the same way. I did use your exact command which did not crash it, but the next select (channel or region) did crash it. This pointed to /strip/trim_db with an impossible strip number. We found two things, trim was sending changed signals forever. Fixed, I was still getting four or five trim signals per trim move... also fixed. Last of all, it appears that the route observers could get called before they were fully initialized... only noticeable because there were so many trim signals. This is also fixed now.

Aside from this. I noted that the default of Auto feedback port detection means that when using a tool like oscsend, each message sent by oscsend creates a new surface profile, all of them sending feedback for every track. The default is now manual port selection. This should also increase stability.

I know this sounds like a "shotgun" approach, but the reality is all of these things needed fixing. Thank you for getting me looking at this use case.

You should be able to test these fixes either with a new nightly or by building from git.
(0019928)
ovenwerks (reporter)
2017-07-24 20:26

Please test a new nightly or build from git to confirm.
(0019940)
rvega (reporter)
2017-07-31 07:57

Compiled from git. The crash does not occurr anymore. Thank you! :)

- Issue History
Date Modified Username Field Change
2017-07-10 15:19 rvega New Issue
2017-07-10 15:19 rvega File Added: ArdourBacktrace 2.txt
2017-07-20 12:45 johmue-eo Note Added: 0019914
2017-07-20 12:45 johmue-eo Status new => feedback
2017-07-20 16:17 ovenwerks Note Added: 0019916
2017-07-22 13:16 rvega Note Added: 0019923
2017-07-22 13:16 rvega Status feedback => new
2017-07-24 20:25 ovenwerks Note Added: 0019927
2017-07-24 20:26 ovenwerks Note Added: 0019928
2017-07-24 20:26 ovenwerks Status new => resolved
2017-07-24 20:26 ovenwerks Resolution open => fixed
2017-07-24 20:26 ovenwerks Assigned To => ovenwerks
2017-07-31 07:57 rvega Note Added: 0019940


Copyright © 2000 - 2017 MantisBT Team
Powered by Mantis Bugtracker