Forum Replies Created
-
AuthorPosts
-
I’ve done some deeper searching and it seems to be the case that Google decided to move strtof (and other similar functions such as atof) from the app-bundled NDK libraries into the standard Android libraries installed on later devices, or something to that effect. The upshot is that if you build an app with later versions of NDK where the strtof symbol is expected to already be on the device, but run the app on an old device… the symbol is missing.
How to solve it? There seem to be two options.
– Use an earlier NDK library to build the app (10d is suggested to work – I am currently downloading it and will try it tomorrow).
– Use a non-google alternative NDK library such as Crystax NDK (https://www.crystax.net/)
This thread has a more detailed discussion of a similar issue :
Does anybody here have any experience with the CrystaX NDK library? Is it something to be recommended that Mark adopt for Monkey? I had never even heard of it until today.
On a side note, another of Linux’s quirks annoys me every time I do a fresh Monkey install. All the *.sh files in /scripts, and the binary /bin/mx2cc all require the exec flag setting before I can run them(chmod a+x …).
If you download it as zip archive; then execute permissions are not saved. The same should be for cloning off of git.
Why would you make life difficult with the zip archive when git clone is so easy? Git *does* honour exec permissions, doesn’t it? At least it moans at me that the permissions have changed whenever I do a git pull.
@Mark would you like me to submit a pull request for this, assuming it is possible?
I managed to reproduce this by installing/building with gcc-6.
There’s a quick ‘n’ dirty fix up now at github, let me know if it works!
Yes, GCC version 6.2.1 here. Probably should have mentioned that earlier!
The fix works perfectly. Many many thanks.
I’m off now to see how Android support is coming on…
You probably suspected as much but all bananas appear show the same behaviour. That is, all the ones I tried : vpaint, monkeyroids, mojotest, glwindowtest.
In debug mode they run fine but in release mode they crash immediately with a memory access violation.
I’m really off to bed now!
Good luck.
Just to be sure, I tried building with ‘-O0’ and it runs as expected and appears fully functional. I guess that will have to do as a fix for now.
I have just uploaded the crashing binary (with build flag -O1) here :
http://www.arpie.co.uk/monkey/ted2
If you’d like me to send you a binary with -O3 too, just ask.
Or anything else I can do that might be helpful, just ask (russell (at) arpie.co.uk).
It has gone midnight here so I’m off to bed. Thanks again for looking into this – I know this is the sort of bug that is a pita to track down.
On a side note, another of Linux’s quirks annoys me every time I do a fresh Monkey install. All the *.sh files in /scripts, and the binary /bin/mx2cc all require the exec flag setting before I can run them(chmod a+x …). It’s easy enough to do, but I presume you could do it at your end to save me having to do it every time? Would you like me to make it a pull request on github (it’s about time I learnt how to)?
Yes, OS and compilers are bang up to date. I came across the same issue with Ted2 when I tried a few months back but didn’t have the time to look into it then, and I’ve updated the OS at least twice since then, so that’s unlikely to be the cause.
Rebuilding with ‘-O2’ produced identical results to ‘-O3’.
Using ‘-O1’ still segfaults but differently :
Monkey123456789101112131415161718192021222324252627282930313233343536(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 27681)][Thread 0x7ffff064f700 (LWP 27681) exited][New Thread 0x7ffff064f700 (LWP 27682)][New Thread 0x7fffefe4e700 (LWP 27683)]Thread 1 "ted2" received signal SIGSEGV, Segmentation fault.t_mojo_app_Style::m_Init (this=this@entry=0x29f7458, l_style=l_style@entry=0x29f7308)at /home/arpie/Coding/Monkey/Monkey2/modules/mojo/mojo.buildv1.0.7/linux_release/src/mojo_app_2style.cpp:168168 this->m__0icons=l_style->m__0icons->slice(bbInt(0));(gdb) bt#0 t_mojo_app_Style::m_Init (this=this@entry=0x29f7458, l_style=l_style@entry=0x29f7308)at /home/arpie/Coding/Monkey/Monkey2/modules/mojo/mojo.buildv1.0.7/linux_release/src/mojo_app_2style.cpp:168#1 0x00000000005c56c9 in t_mojo_app_Style::t_mojo_app_Style (this=0x29f7458, l_style=0x29f7308)at /home/arpie/Coding/Monkey/Monkey2/modules/mojo/mojo.buildv1.0.7/linux_release/src/mojo_app_2style.cpp:29#2 0x00000000005c0cb6 in bbGCNew<t_mojo_app_Style, t_mojo_app_Style*> ()at /home/arpie/Coding/Monkey/Monkey2/modules/monkey/native/bbobject.h:48#3 t_mojo_app_Theme::m_LoadStyle (this=this@entry=0xb90650, l_name=<optimized out>)at /home/arpie/Coding/Monkey/Monkey2/modules/mojo/mojo.buildv1.0.7/linux_release/src/mojo_app_2theme.cpp:352#4 0x00000000005c198f in t_mojo_app_Theme::t_mojo_app_Theme (this=0xb90650, l_path=..., l_jobj=0x29f7248)at /home/arpie/Coding/Monkey/Monkey2/modules/mojo/mojo.buildv1.0.7/linux_release/src/mojo_app_2theme.cpp:70#5 0x00000000005c28ce in bbGCNew<t_mojo_app_Theme, bbString, t_std_json_JsonObject*> (a#0=..., a#1=0x29f7248)at /home/arpie/Coding/Monkey/Monkey2/modules/monkey/native/bbobject.h:48#6 0x00000000005c20ac in g_mojo_app_Theme_Load (l_path=...)at /home/arpie/Coding/Monkey/Monkey2/modules/mojo/mojo.buildv1.0.7/linux_release/src/mojo_app_2theme.cpp:39#7 0x00000000005c95ac in t_mojo_app_AppInstance::t_mojo_app_AppInstance (this=0xba21b8, l_config=<optimized out>)at /home/arpie/Coding/Monkey/Monkey2/modules/mojo/mojo.buildv1.0.7/linux_release/src/mojo_app_2app.cpp:96#8 0x000000000040bee6 in bbGCNew<t_mojo_app_AppInstance, t_std_collections_Map_1ss*> ()at /home/arpie/Coding/Monkey/Monkey2/modules/monkey/native/bbobject.h:48#9 bbMain () at /home/arpie/Coding/Monkey/Monkey2/src/ted2/ted2.buildv1.0.7/linux_release/src/ted2_ted2.cpp:59#10 0x0000000000777540 in main (argc=<optimized out>, argv=<optimized out>)at /home/arpie/Coding/Monkey/Monkey2/modules/monkey/native/bbmonkey.cpp:71(gdb)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.
Does that mean that
Monkey1Field blah:Image[]is equivalent to
Monkey1Field blah:Image[] = New Image[0]?
Here is a backtrace of the original segfault, with none of my edits to the mojo code :
Monkey123456789101112131415161718192021222324252627282930313233343536(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 17122)][Thread 0x7ffff064f700 (LWP 17122) exited][New Thread 0x7ffff064f700 (LWP 17123)][New Thread 0x7fffefe4e700 (LWP 17124)]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:166166 this->m__0textColor=t_std_graphics_Color(l_style->m__0textColor);(gdb) bt#0 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:166#1 0x000000000071dfb2 in t_mojo_app_Style::t_mojo_app_Style (this=0x2c51458, l_style=0x2c51308)at /home/arpie/Coding/Monkey/Monkey2/modules/mojo/mojo.buildv1.0.7/linux_release/src/mojo_app_2style.cpp:29#2 0x0000000000716b46 in bbGCNew<t_mojo_app_Style, t_mojo_app_Style*> ()at /home/arpie/Coding/Monkey/Monkey2/modules/monkey/native/bbobject.h:48#3 t_mojo_app_Theme::m_LoadStyle (this=this@entry=0xdea650, l_name=<optimized out>)at /home/arpie/Coding/Monkey/Monkey2/modules/mojo/mojo.buildv1.0.7/linux_release/src/mojo_app_2theme.cpp:352#4 0x0000000000718217 in t_mojo_app_Theme::t_mojo_app_Theme (this=0xdea650, l_path=..., l_jobj=0x2c51248)at /home/arpie/Coding/Monkey/Monkey2/modules/mojo/mojo.buildv1.0.7/linux_release/src/mojo_app_2theme.cpp:70#5 0x0000000000719500 in bbGCNew<t_mojo_app_Theme, bbString, t_std_json_JsonObject*> ()at /home/arpie/Coding/Monkey/Monkey2/modules/monkey/native/bbobject.h:48#6 g_mojo_app_Theme_Load (l_path=...)at /home/arpie/Coding/Monkey/Monkey2/modules/mojo/mojo.buildv1.0.7/linux_release/src/mojo_app_2theme.cpp:39#7 0x0000000000727166 in t_mojo_app_AppInstance::t_mojo_app_AppInstance (this=0xdfc1b8, l_config=<optimized out>)at /home/arpie/Coding/Monkey/Monkey2/modules/mojo/mojo.buildv1.0.7/linux_release/src/mojo_app_2app.cpp:96#8 0x00000000004173dc in bbGCNew<t_mojo_app_AppInstance, t_std_collections_Map_1ss*> ()at /home/arpie/Coding/Monkey/Monkey2/modules/monkey/native/bbobject.h:48#9 bbMain () at /home/arpie/Coding/Monkey/Monkey2/src/ted2/ted2.buildv1.0.7/linux_release/src/ted2_ted2.cpp:59#10 0x0000000000416a30 in main (argc=<optimized out>, argv=<optimized out>)at /home/arpie/Coding/Monkey/Monkey2/modules/monkey/native/bbmonkey.cpp:71@Mark: I will await further instructions from you before doing anything else!
Hello Mark. Do you want to see a backtrace of each of the segfaults I’ve mentioned so far? I can see this thread quickly getting messy if I try to retrace my steps with backtraces. Shall I start with a backtrace of the original segfault before I altered any mojo code? Are my further experiments any use to you?
Okay, I’m muddling on, hopefully in a vaguely useful direction. It seems that the above issue is related to line 170 of mojox/filebrowser.monkey2 and is entirely due to the variable children being null. If I change line 170 from :
Monkey1234567168: Local child:Node169:170: If i<children.Length171: child=Cast<Node>( children[i] )172: Else173: child=New Node( node )174: Endifto
Monkey1234567168: Local child:Node169:170: If children And i<children.Length171: child=Cast<Node>( children[i] )172: Else173: child=New Node( node )174: Endifthen the segfault goes away. But I suspect we need to address the reason why children is null and this is just a fudge. But, guess what, new segfault…!
Monkey12345678910111213141516Reading 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 16840)][Thread 0x7ffff064f700 (LWP 16840) exited][New Thread 0x7ffff064f700 (LWP 16841)][New Thread 0x7fffefe4e700 (LWP 16842)]SDL_WINDOWEVENT_FOCUS_GAINEDThread 1 "ted2" received signal SIGSEGV, Segmentation fault.0x00000000007b0473 in bbString::release (this=<optimized out>)at /home/arpie/Coding/Monkey/Monkey2/modules/monkey/native/bbstring.h:4848 if( !--_rep->refs && _rep!=&_nullRep ) bbFree( _rep );(gdb)So I went with my hunch from earlier and added a line to the empty New() method of class Style in mojo/style.monkey2 :
Monkey12348: Method New()9: _icons = New Image[1]10: EndAnd reran it through the debugger. The good news is I now get a window shown on screen (previously I got nothing at all). The bad news is the window is black and empty and there is a new segfault :
Monkey12345678910111213141516Reading 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 16358)][Thread 0x7ffff064f700 (LWP 16358) exited][New Thread 0x7ffff064f700 (LWP 16359)][New Thread 0x7fffebe4e700 (LWP 16360)]Thread 1 "ted2" received signal SIGSEGV, Segmentation fault.0x00000000005a3188 in t_mojox_FileBrowser::m_UpdateNode (this=this@entry=0x436dc88, l_node=0x4359130,l_path=..., l_recurse=l_recurse@entry=true)at /home/arpie/Coding/Monkey/Monkey2/modules/mojox/mojox.buildv1.0.7/linux_release/src/mojox_filebrowser.cpp:145145 if((l_i<f0.l_children->length())){(gdb)Any thoughts? I’m feeling quite out of my depth but willing to try anything to help…
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.
Monkey12345678910111213141516Reading 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++.
@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 :
Monkey1style._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.
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.
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 :
Monkey123456789101112131415[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
-
AuthorPosts