This topic contains 37 replies, has 4 voices, and was last updated by 
dawlane 2 years, 6 months ago.
-
Posts
-
Hello,
It looks like open-al and jack are having trouble but (if you’ll excuse the pun) I don’t know jack.
I am trying to use monkey2 and Ted2 under Archlinux in Gnome (that means Pulseaudio is running and afaik that doesn’t play nice with jack?)
Why does Ted2 require jack support, anyway? Surely open-al can directly use Pulseaudio? Anyway, I’ll stop speculating and paste some error messages…
I have just cloned the monkey2 git repo and ran ./rebuildall.sh then tried to run the Monkey2 (Linux) binary. It does nothing (no errors, nothing, even on command line). I then tried running bin/ted2_linux/ted2 and get the following output :
1234567[arpie@max Monkey2]$ bin/ted2_linux/ted2Cannot connect to server socket err = No such file or directoryCannot connect to server request channeljack server is not running or cannot be startedCaught signal:Memory access violationAL lib: (EE) alc_cleanup: 1 device not closedSo I installed and ran ‘qjackctl’ which allowed me to start a jack server. With a running jack server, I tried again :
12345678[arpie@max Monkey2]$ bin/ted2_linux/ted2Cannot lock down 82274202 byte memory area (Cannot allocate memory)Cannot lock down 82274202 byte memory area (Cannot allocate memory)Cannot use real-time scheduling (RR/5)(1: Operation not permitted)JackClient::AcquireSelfRealTime errorCaught signal:Memory access violationAL lib: (EE) alc_cleanup: 1 device not closedAny suggestions greatly appreciated !
Russell
I think monkey2 on Linux uses OpenAL configured as it finds it so you probably want to start with some plain openal tests.
According to this page OpenAL Soft should use PulseAudio by default, but can be explicitly configured to do so:
1/etc/openal/alsoft.conf1drivers=pulse,alsaThanks a lot Simon, that made the jack errors go away. I am now left with :
1234[arpie@max Monkey2]$ bin/ted2_linux/ted2Caught signal:Memory access violationAL lib: (EE) alc_cleanup: 1 device not closedI have no idea what is causing that memory access violation.
Any other ideas? How can I go about running Ted2 with some extra debugging output turned on?
Russell
Curiouser and curiouser…
I have managed to do a debug build of ted2 (by setting -config=debug in /scripts/rebuildted2.sh) and, well, it runs perfectly.
The release version crashes immediately (no window, nothing) but the debug build runs and is perfectly useable. Here’s some console output :
123456789101112131415[arpie@max ted2.buildv1.0.7]$ lslinux_debug linux_release[arpie@max ted2.buildv1.0.7]$ linux_release/ted2Caught signal:Memory access violationAL lib: (EE) alc_cleanup: 1 device not closed[arpie@max ted2.buildv1.0.7]$ linux_debug/ted2SDL_WINDOWEVENT_FOCUS_GAINEDGtk-Message: GtkDialog mapped without a transient parent. This is discouraged.SDL_WINDOWEVENT_FOCUS_LOSTSDL_WINDOWEVENT_FOCUS_GAINEDAL lib: (EE) alc_cleanup: 1 device not closed[arpie@max ted2.buildv1.0.7]$I can live with using the debug build for now but it would be nice to have it working as it should with the release build. Any suggestions what to try next?
Regards,
Russell
It looks like there are two issues there for maybe Mark to take a look at.
- audio.monkey2 calls alcOpenDevice but there is no matching CloseDevice to be found
2. the zenity system monkey2 uses for requesters may have issues, the thread here suggests an environment variable can fix it
I guess both those things would be good to get fixed but neither seem linked to the ‘memory address violation’ that causes a crash with the release build, but which doesn’t occur with a debug build. Gtk is notorious for dumping warnings to the console even though the UI behaves normally so you shouldn’t pay much attention to those gtk messages. Also, the alc_cleanup error occurs when ted2 exits so is not a major issue. It’s the ‘memory access violation’ that needs the attention of somebody cleverer than me.
The zenity issue has been a deal breaker for others causing complete crash.
Your crash probably needs a release with debug symbols style build so gdb can be used to backtrace the cause.
I think monkey2 on Linux uses OpenAL configured
mx2 uses the distro version of openal on linux.
I have no idea what is causing that memory access violation.
Works fine here, but I just tried to valgrind it and it crashed valgrind with an internal error. It did get as far as opening a window and printing SDL_GOT_FOCUS. Is this where it crashes for you?
Next thing I’d suggest trying is adding symbols to release mode via the -g flag (in bin/env_linux.txt), eg:
123456789101112131415'LD optionsMX2_LD_OPTS_LINUX=MX2_LD_OPTS_LINUX_DEBUG=MX2_LD_OPTS_LINUX_RELEASE=-g -O3'C compiler optionsMX2_CC_OPTS_LINUX=-std=gnu99MX2_CC_OPTS_LINUX_DEBUG=MX2_CC_OPTS_LINUX_RELEASE=-g -O3 -DNDEBUG'C++ compiler optionsMX2_CPP_OPTS_LINUX=-std=c++11MX2_CPP_OPTS_LINUX_DEBUG=MX2_CPP_OPTS_LINUX_RELEASE=-g -O3 -DNDEBUGYou’ll need to rebuild all modules and ted2 after changing this file.
You should then be able to debug it with gdb:
123cd bin/ted2_linuxgdb ./ted2[type 'run' in gdb]If that fixes it, you’re boned.
If not and you still can’t see where the problem is, try removing ‘-DNDEBUG’ and/or reducing ‘-O’ level until it’s the same as debug, ie: 0.
If valgrind doesn’t reveal the issue Address Sanitizer might.
We have been using it at work and typically involves using recent gcc (or clang) and -fsanitize=address flag for both compile and link.
It will slow down your program 2x (not as bad as valgrind) but manages to trap most bad memory operations.
Ok, gave address sanitizer a go, using “-g -fsanitize=address” for compile/link.
Ted2 starts and runs fine with this, but locks up HARD for about a minute at exit before print ing’killed’ and fnally ending.
Should the sanitizer thing be showing some output?
@Mark: You will only see output if there are errors with -fsanitize. If, anything. I would be looking at why Jack is a requirement. That to me would seem to be the problem.
You have to be a hard core Linux user to be able to set the Arch Linux distribution up correctly.
A few thoughts (sorry not set up to actually help atm).
- I’m not sure sanitize will work on a vm, the way I understand it, it severely abuses the PMMU to do it’s thing
- I’m not sure a monkey2 app can be trusted to close down corrctly on linux without cleaning up the audio context and closing the device correctly
- the killed scenario and valgrind issues sounds to me like there is something amiss… (will look into it on my work machine on monday)
- both valgrind and asan may not be compatible / usable with monkey2 fibers
@Mark: many thanks for taking a look at this, I know your time is precious and I suspect you probably don’t have many other Archlinux users using Monkey!
I had a play yesterday with adding copious amounts of Print() statements to the source files (I’ve never been keen on debuggers) and narrowed down the issue to the Style class of mojo, specifically if I comment out the line :
1style._icons.Slice( 0 )in function Init() of class Style, then I no longer get a crash.
Admittedly, I just get a blank window so there is more to it, but the memory issue seems to be related to the use of the _icons:Image[] field. I’m rusty on how to initialise arrays in monkey… is the field declaration sufficient to allocate memory for an empty array? Or does it need a _icons = New Array() or some such somewhere?
As for Jack, that was a red herring. Since configuring OpenAl to use PulseAudio, this no longer seems to be relevant. I have never needed or used jack so my installation is almost certainly borked. I’ve never needed OpenAl until now, either.
I will try the -g flag now and see what it turns up.
So I tried the -g flag as instructed by Mark. It crashed close to where I suspected the problem to be but I’m now baffled. Does this mean anything to you guys? Like I said earlier, debuggers and me don’t get on.
12345678910111213141516Reading symbols from ./ted2...done.(gdb) runStarting program: /home/arpie/Coding/Monkey/Monkey2/bin/ted2_linux/ted2[Thread debugging using libthread_db enabled]Using host libthread_db library "/usr/lib/libthread_db.so.1".[New Thread 0x7ffff064f700 (LWP 16157)][Thread 0x7ffff064f700 (LWP 16157) exited][New Thread 0x7ffff064f700 (LWP 16158)][New Thread 0x7fffebe4e700 (LWP 16159)]Thread 1 "ted2" received signal SIGSEGV, Segmentation fault.0x000000000071d8d9 in t_mojo_app_Style::m_Init (this=this@entry=0x2c51458, l_style=l_style@entry=0x2c51308)at /home/arpie/Coding/Monkey/Monkey2/modules/mojo/mojo.buildv1.0.7/linux_release/src/mojo_app_2style.cpp:167167 this->m__0textColor=t_std_graphics_Color(l_style->m__0textColor);(gdb)I tracked down line 167 of the cpp source file but can’t see any reason why that line would cause an issue… then again it has been a long time since I wrote much c++.
is the field declaration sufficient to allocate memory for an empty array?
Yes, a ‘null’ array in mx2 is really just an array of length 0, ditto strings.
Had a quick look at the code and it seems OK, so this may just be a symptom, not the cause. And if code *was* trying to read from an empty array, all hell should break loose on all platforms!
You must be logged in to reply to this topic.