View Issue Details

IDCategoryLast Update
0008190other2020-06-03 14:28
Reporterthebarfly1Assigned To 
Reproducibilityalways 
Status feedbackResolutionopen 
PlatformWindows 10OSWindowsOS Version10
Product Version6.0 
Fixed in Version 
Summary0008190: Crash GLib Error in large session
DescriptionWhen working on a large session (about 50 tracks), Ardour is running slowly and crashing when I attempt to save the session, and suffering hanging which sometimes leads to the same error message periodically.

Attached are error message given and a copy of the session file, session history etc.
Steps To Reproduce1- Open session
2- Do anything
3- Attempt to save session
Additional InformationHave tried reinstallation, removing some plugins, removing some tracks & busses all to no avail.

There is a warning in the (Hud? Log?- top right corner) warning of ambiguous latency on one of the tracks but I'm not sure if that is related to the crash - the session had been running/saving just fine several hours earlier while displaying the same message.

I don't think it's a computer performance issue as I had reduced dsp load significantly by bouncing all vsti midi tracks to .wav files hours before any issues arose. I had also removed about a dozen tracks that I had decided to cut from the session. There were no performance issues while the other tracks and virtual instruments were still present.

I'm running a 3.2ghz i5 with 16GB RAM, GTX1050ti, reading and writing from 2 solid state drives. Audio Interface is an MBox 3, most running plugins are Melda EQ's/Compressors, NI Supercharger Compressor, EW Spaces verbs, LiSp De-esser, and some others here or there that had been running perfectly fine both on Ardour 6 and 5 until now.

I had been trying out Reapers free ReaEQ and ReaDelay plugs for the first time on the same day as the issue arose, but removed them while in safe mode and the issue remains when session is loaded with plugins enabled.
TagsNo tags attached.

Activities

thebarfly1

2020-06-02 05:09

reporter  

ardourerror.jpg (31,391 bytes)
ardourerror.jpg (31,391 bytes)
problemsession.zip (273,438 bytes)

johne53

2020-06-02 07:45

reporter   ~0024344

You mentioned that it saves okay if you load in safe mode so there's a good chance this'll be plugin related. I know you've tried removing certain plugins - but make a safe copy of your session (i.e. the main ".ardour" file) then launch Ardour in safe mode and try removing ALL the plugins and saving. Does it then save normally if you reload in normal mode (i.e. with ALL the plugins removed) ?

johne53

2020-06-02 09:09

reporter   ~0024345

Question for the developers - this might be a red herring but I just noticed something suspicious in VSTPlugin::::get_chunk()

    return g_base64_encode (data, data_size);

where 'data_size' is a signed int32_t - should it maybe be unsigned? Or of type 'size_t' / 'gsize' or whatever?

x42

2020-06-02 19:36

administrator   ~0024351

The dispatcher expects a byte-size as VstInt32 so that part is correct. It could well be that a plugin returns an invalid value, though.

x42

2020-06-02 19:43

administrator   ~0024352

Does this only happen with a specific session? If so, can you post the *.ardour session file of that session?

johne53

2020-06-03 14:28

reporter   ~0024367

Posted by x42:
" It could well be that a plugin returns an invalid value, though "

Yes, my guess is that there's some plugin returning the address of the chunk, rather than its size.

thebarfly1 - Whenever you get a chance, can you try the experiment I mentioned (above) and also upload your faulty ".ardour" file? Thanks...

Issue History

Date Modified Username Field Change
2020-06-02 05:09 thebarfly1 New Issue
2020-06-02 05:09 thebarfly1 File Added: ardourerror.jpg
2020-06-02 05:09 thebarfly1 File Added: problemsession.zip
2020-06-02 07:45 johne53 Note Added: 0024344
2020-06-02 09:09 johne53 Note Added: 0024345
2020-06-02 19:36 x42 Note Added: 0024351
2020-06-02 19:43 x42 Note Added: 0024352
2020-06-02 19:43 x42 Status new => feedback
2020-06-03 14:28 johne53 Note Added: 0024367