View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0008190 | ardour | other | public | 2020-06-02 05:09 | 2020-06-03 14:28 |
Reporter | thebarfly1 | Assigned To | |||
Priority | normal | Severity | minor | Reproducibility | always |
Status | feedback | Resolution | open | ||
Platform | Windows 10 | OS | Windows | OS Version | 10 |
Product Version | 6.0 | ||||
Summary | 0008190: Crash GLib Error in large session | ||||
Description | When 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 Reproduce | 1- Open session 2- Do anything 3- Attempt to save session | ||||
Additional Information | Have 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. | ||||
Tags | No tags attached. | ||||
|
|
|
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) ? |
|
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? |
|
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. |
|
Does this only happen with a specific session? If so, can you post the *.ardour session file of that session? |
|
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... |
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 |