When I reduced the size of the icons (to reduce memory consumption) it triggered a bug wrt boost.
This is present in MASTER (b5895d62e04b97f36ce5e9a686db4af85947777d at the time of writing)
The commit that introduced this error is: 0cf3e2d5a043c377fa654c08c815165946e63931
The error has two visible forms:
libc++abi.dylib: terminating with uncaught exception of type boost::interprocess::interprocess_exception: No such file or directory
zsh: abort ./build/Sonic\ Pi.app/Contents/MacOS/Sonic\ Pi
This doesn't appear to be related directly to any specific image. In fact, it can be triggered by having some images small and some big, which indicates that it's something to do with the amount of memory allocated to the icon images.
@kisielk suggested he might be able to shed some light on this.
Any help from anyone in figuring out how to even start debugging this would be amazing!
Funny, I was just going to report this and did some research. For me, the startup of Sonic-Pi fails at opening the shared memory file of SuperCollider:
statfs("/dev/shm/", {f_type=TMPFS_MAGIC, f_bsize=4096, f_blocks=2034836, f_bfree=1884387, f_bavail=1884387, f_files=2034836, f_ffree=2034464, f_fsid={val=[0, 0]}, f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_NOSUID|ST_NODEV}) = 0
futex(0x7f86598303b0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
openat(AT_FDCWD, "/dev/shm/SuperColliderServer_51237", O_RDWR|O_NOFOLLOW|O_CLOEXEC) = -1 ENOENT (No such file or directory)
But the strange part is, that this file does exist after the crash (with the sonic-pi-server.rb and beam.smp erlang processes still alive) so it looks to me as a race with SuperCollider as I managed to start 3.2.0-dev once as root (but that doesn't seem related, because I can make it fail as root as well).
Ooh, this is useful, thanks.
Maybe the problem has allways been there but was triggered by the smaller icons taking less time to start?
Yes, this is my hunch too - that it's a timing issue rather than a memory one. Am following this trail right now. Fingers crossed...
This could fit with the fact that it still builds and starts up OK with Scope working on Raspbian Buster on a Pi4, which will be a bit slower.
This did crash until the QSzize parameters where changed to integers.
On 19 Jul 2019, at 15:31, Sam Aaron notifications@github.com wrote:
Yes, this is my hunch too - that it's a timing issue rather than a memory one. Am following this trail right now. Fingers crossed...
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/samaaron/sonic-pi/issues/2104?email_source=notifications&email_token=ABKUHCOZW7TBRTIL7MDZXUTQAHF4HA5CNFSM4IFDMUD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2LZTJA#issuecomment-513251748, or mute the thread https://github.com/notifications/unsubscribe-auth/ABKUHCLX6EQVGE7MN2OEQKTQAHF4HANCNFSM4IFDMUDQ.
Compiling a possible fix right now. Wish me luck!
I believe this is now solved. Thanks so much to @mrvanes for pointing me in the right direction. Ik hou van jou! 💕
Oops
In file included from scope.cpp:14:
scope.h: In constructor ‘Scope::Scope(int, QWidget*)’:
scope.h:110:7: error: ‘Scope::scsynthPort’ will be initialized after [-Werror=reorder]
int scsynthPort;
^~~~~~~~~~~
scope.h:108:8: error: ‘bool Scope::scsynthIsBooted’ [-Werror=reorder]
bool scsynthIsBooted;
^~~~~~~~~~~~~~~
scope.cpp:138:1: error: when initialized here [-Werror=reorder]
Scope::Scope( int scsynthPort, QWidget* parent ) : QWidget(parent), paused( false ), emptyFrames(0), scsynthPort(scsynthPort), scsynthIsBooted (false )
^~~~~
cc1plus: all warnings being treated as errors
make: *** [Makefile:4185: scope.o] Error 1
Which can be fixed this way:
$ git diff
diff --git a/app/gui/qt/scope.h b/app/gui/qt/scope.h
index 7b88448db..c30dd8cc5 100644
--- a/app/gui/qt/scope.h
+++ b/app/gui/qt/scope.h
@@ -105,9 +105,9 @@ private:
scope_buffer_reader shmReader;
std::vector<std::shared_ptr<ScopeBase>> panels;
bool paused;
- bool scsynthIsBooted;
unsigned int emptyFrames;
int scsynthPort;
+ bool scsynthIsBooted;
};
#endif
Warnings on code ordering, somebody must be kidding, right?
Using this patch, Sonic Pi 3.2.0-dev now builds and runs like a charm on my Ubuntu 19.04 laptop.
Most helpful comment
Compiling a possible fix right now. Wish me luck!