Skip to main content

News

Topic: neoSphere 5.9.2 (Read 522604 times) previous topic - next topic

0 Members and 17 Guests are viewing this topic.
  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: miniSphere 4.8.5
Reply #2085
I finally got some time to compile miniSphere today. It works when I sudo make install, but locally it just goes:

Code: [Select]
./minisphere: error while loading shared libraries: libChakraCore.so: cannot open shared object file: No such file or directory

The startup game runs properly if I do a global install.

Edit: running a game (Aquatis) from the startup fails with a little popup window with a grammar error though:
Code: [Select]
Engine initialized failed.
The console just segfaults at this point.
  • Last Edit: September 10, 2017, 06:17:26 am by DaVince

  • Rhuan
  • [*][*][*][*]
Re: miniSphere 4.8.5
Reply #2086
I finally got some time to compile miniSphere today. It works when I sudo make install, but locally it just goes:

Code: [Select]
./minisphere: error while loading shared libraries: libChakraCore.so: cannot open shared object file: No such file or directory

The startup game runs properly if I do a global install.

Edit: running a game (Aquatis) from the startup fails with a little popup window with a grammar error though:
Code: [Select]
Engine initialized failed.
The console just segfaults at this point.
I think it's just that Execute Game is broken in the CC version at the moment, try opening a game by opening the .sgm or .json with miniSphere.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.8.5
Reply #2087
I finally got some time to compile miniSphere today. It works when I sudo make install, but locally it just goes:

Code: [Select]
./minisphere: error while loading shared libraries: libChakraCore.so: cannot open shared object file: No such file or directory

@DaVince That's expected, unfortunately.  Unlike Windows, Linux won't just load shared libraries (Linux equivalent to a DLL) from the program directory, you have to install the .so to a known location.  And there are no ChakraCore packages for Ubuntu yet, not even a PPA.  The final release will be static linked to CC to avoid the issue.

And yeah, like @Rhuan said, ExecuteGame() is broken at the moment :(
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.8.5
Reply #2088
Huh, weird.  ExecuteGame() works perfectly on Windows, I can't reproduce the crash in either a Debug or Release build.  I'll try on Linux.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.8.5
Reply #2089
Yep, segfault on Linux when calling ExecuteGame.  I fired up GDB and this is what I got:
Code: [Select]
minisphere: malloc.c:2868: mremap_chunk: Assertion `((size + offset) & (GLRO (dl_pagesize) - 1)) == 0' failed.

Looks like some sort of heap corruption.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: miniSphere 4.8.5
Reply #2090
I finally got some time to compile miniSphere today. It works when I sudo make install, but locally it just goes:

Code: [Select]
./minisphere: error while loading shared libraries: libChakraCore.so: cannot open shared object file: No such file or directory

@DaVince That's expected, unfortunately.  Unlike Windows, Linux won't just load shared libraries (Linux equivalent to a DLL) from the program directory, you have to install the .so to a known location.  And there are no ChakraCore packages for Ubuntu yet, not even a PPA.  The final release will be static linked to CC to avoid the issue.

And yeah, like @Rhuan said, ExecuteGame() is broken at the moment :(
Ah, that is too bad. Looking into it, this could be fixed by adding -R <path> to the make command. Perhaps this could be added to the makefile in a way too.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.8.5
Reply #2091
And well, here's the problem:
Code: [Select]
#5  0x0000000000418df5 in ensure_space (vector=0x7b42a0, min_items=33)
    at src/shared/vector.c:192
192 if (!(new_buffer = realloc(vector->buffer, new_max * vector->pitch)) && new_max > 0)
(gdb) l
187 if (min_items > vector->max_items)  // is the buffer too small?
188 new_max = min_items * 2;
189 else if (min_items < vector->max_items / 4)  // if item count drops below 1/4 of peak size, shrink the buffer
190 new_max = min_items;
191 if (new_max != vector->max_items) {
192 if (!(new_buffer = realloc(vector->buffer, new_max * vector->pitch)) && new_max > 0)
193 return false;
194 vector->buffer = new_buffer;
195 vector->max_items = new_max;
196 }
(gdb) p new_max
$1 = 66
(gdb) p vector->pitch
$2 = 140701562626560

realloc() gets asked to allocate 9 quadrillion bytes and, well, that obviously fails miserably. :P
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.8.5
Reply #2092
Okay, well, the crashes themselves are fixed, but the underlying problem remains: The engine fails to reinitialize after an ExecuteGame().  I haven't figured out if that's related to ChakraCore or something else.  I can't reproduce it on Windows though, which is weird.

Oh, and I fixed the ungrammatical error message. ;)
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.8.4
Reply #2093
I'm getting a (slightly) less obnoxious error message now when building the chakra-js branch in Deian
Code: [Select]
minisphere: malloc.c:2883: mremap_chunk: Assertion `((size + offset) & (GLRO (dl_pagesize) - 1)) == 0' failed.
Aborted

This sounds like the bug I just fixed (exact same error), after calling ExecuteGame() the engine fails to reinitialize but continues running anyway, eventuallly leading to a bad realloc and subsequent crash.  Does the CC-enabled build run at all?
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Rhuan
  • [*][*][*][*]
Re: miniSphere 4.8.5
Reply #2094
I've got a feature request that may sound a bit odd...

Please can we have shapes and shaders and surfaces available in cell. I want to run:
- my map loading script in cell (it draws all the tiles on a layer to make one image for that layer)
- my rss loader (it combines the frames into an atlas)
- some similar animation code I've just been thinking of (again combine a stack of frames into an atlas)

Thoughts? Possible?

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.8.5
Reply #2095
That would mean taking a dependency on Allegro, which seems a bit bloaty for a command-line tool.  In fact having a whole rendering pipeline in a compiler seems like a lot of extra complexity to me.

That said, I did want to have some kind of image-manipulation built-in, as raw JavaScript is just not suited to it, even with ArrayBuffers.  I had a libpng-based image loader in the codebase originally (not exposed to the API), but it got blown away when I rewrote the compiler from the ground up for miniSphere 4.4.

What you describe is in fact exactly the kind of thing Cell was designed for.  It's just that I never wrote the bindings for it. ;)
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Rhuan
  • [*][*][*][*]
Re: miniSphere 4.8.5
Reply #2096
Hmm thinking about it I'd be happy doing the image manipulation with an image object that was simply:
Code: [Select]
{
  width:num_pixels,
  height:num_pixels,
  data:array_of_pixels
}
The array could just be 1d but with each element being a color object (or equivalent - just needs the rgba values)

Don't need a 2d construct as can work fine with specified width to tell you which row you're on (could have a helper function that converts coordinates to an index location); as I'd want to combine images having a more complex interface would probably make it harder.

The key things I'd need which we don't have at the moment are methods to:
a) convert png/jpeg files to width + height + pixel array
b) save a width + height + pixel array in such a way that reading it in as an ArrayBuffer and then calling new Texture on it in miniSphere will work.

I probably could implement all of that in JS but it may be slightly painful.


EDIT: Hmm, lets see where I can get to with this starting point: https://github.com/arian/pngjs
  • Last Edit: September 10, 2017, 05:29:25 pm by Rhuan

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.8.5
Reply #2097
Ah, that is too bad. Looking into it, this could be fixed by adding -R <path> to the make command. Perhaps this could be added to the makefile in a way too.

Thanks for looking into that for me @DaVince, that worked great!  One just has to set the executable's RPATH to $ORIGIN and then it automatically loads dynamic libraries from the same directory as itself, just like in Windows :)
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.8.5
Reply #2098
Edit: running a game (Aquatis) from the startup fails with a little popup window with a grammar error though:
Code: [Select]
Engine initialized failed.
The console just segfaults at this point.

Interesting, I stepped through the initialization process with GDB and the second time JsCreateContext() is called it fails with a "wrong thread" error.  This makes no sense since the same thread is creating the context that created the runtime.  The only thing I can think of is that me longjmp'ing totally clear of the JS engine in order to do ExecuteGame is corrupting stuff.  Duktape didn't seem to mind me doing that, but Chakra has a lot more that can go wrong.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: miniSphere 4.8.5
Reply #2099
Here is valgrind's output of the 4.8.4 release
Code: [Select]
==3468== Conditional jump or move depends on uninitialised value(s)
==3468==    at 0x4C32EA6: rawmemchr (vg_replace_strmem.c:1402)
==3468==    by 0x67DA391: _IO_str_init_static_internal (strops.c:41)
==3468==    by 0x67CDB66: vsscanf (iovsscanf.c:40)
==3468==    by 0x67C82D6: sscanf (sscanf.c:32)
==3468==    by 0xF547E4A: ??? (in /usr/lib/x86_64-linux-gnu/libdrm.so.2.4.0)
==3468==    by 0xF548182: ??? (in /usr/lib/x86_64-linux-gnu/libdrm.so.2.4.0)
==3468==    by 0xF54BBF8: drmGetDevice (in /usr/lib/x86_64-linux-gnu/libdrm.so.2.4.0)
==3468==    by 0x94932D6: ??? (in /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0)
==3468==    by 0x9492694: ??? (in /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0)
==3468==    by 0x9466988: ??? (in /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0)
==3468==    by 0x9461F10: glXQueryVersion (in /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0)
==3468==    by 0x5D470B8: ??? (in /usr/lib/x86_64-linux-gnu/liballegro.so.5.2.2)
==3468==
(Now I press Escape, select Exit and...)
==3468== Invalid read of size 4
==3468==    at 0x1902DE: image_unref (image.c:272)
==3468==    by 0x1A9A64: screen_free (screen.c:145)
==3468==    by 0x112797: shutdown_engine (main.c:484)
==3468==    by 0x111BFD: main (main.c:167)
==3468==  Address 0x2a10e590 is 0 bytes inside a block of size 112 free'd
==3468==    at 0x4C2CDDB: free (vg_replace_malloc.c:530)
==3468==    by 0x190369: image_unref (image.c:282)
==3468==    by 0x1A81D2: js_Surface_finalize (pegasus.c:4095)
==3468==    by 0x149B46: duk__handle_call_inner (duk_js_call.c:1619)
==3468==    by 0x14906F: duk_handle_call_unprotected (duk_js_call.c:1149)
==3468==    by 0x1185B9: duk_call (duk_api_call.c:60)
==3468==    by 0x13A10B: duk__finalize_helper (duk_heap_finalize.c:368)
==3468==    by 0x14AAA4: duk__handle_safe_call_inner (duk_js_call.c:2131)
==3468==    by 0x14A91B: duk_handle_safe_call (duk_js_call.c:1972)
==3468==    by 0x118928: duk_safe_call (duk_api_call.c:228)
==3468==    by 0x13A18A: duk_heap_run_finalizer (duk_heap_finalize.c:430)
==3468==    by 0x139903: duk__free_run_finalizers (duk_heap_alloc.c:206)
==3468==  Block was alloc'd at
==3468==    at 0x4C2DBC5: calloc (vg_replace_malloc.c:711)
==3468==    by 0x18F787: image_new (image.c:69)
==3468==    by 0x1A98DB: screen_new (screen.c:100)
==3468==    by 0x111E9D: main (main.c:227)
==3468==
==3468== Invalid write of size 4
==3468==    at 0x1902E7: image_unref (image.c:272)
==3468==    by 0x1A9A64: screen_free (screen.c:145)
==3468==    by 0x112797: shutdown_engine (main.c:484)
==3468==    by 0x111BFD: main (main.c:167)
==3468==  Address 0x2a10e590 is 0 bytes inside a block of size 112 free'd
==3468==    at 0x4C2CDDB: free (vg_replace_malloc.c:530)
==3468==    by 0x190369: image_unref (image.c:282)
==3468==    by 0x1A81D2: js_Surface_finalize (pegasus.c:4095)
==3468==    by 0x149B46: duk__handle_call_inner (duk_js_call.c:1619)
==3468==    by 0x14906F: duk_handle_call_unprotected (duk_js_call.c:1149)
==3468==    by 0x1185B9: duk_call (duk_api_call.c:60)
==3468==    by 0x13A10B: duk__finalize_helper (duk_heap_finalize.c:368)
==3468==    by 0x14AAA4: duk__handle_safe_call_inner (duk_js_call.c:2131)
==3468==    by 0x14A91B: duk_handle_safe_call (duk_js_call.c:1972)
==3468==    by 0x118928: duk_safe_call (duk_api_call.c:228)
==3468==    by 0x13A18A: duk_heap_run_finalizer (duk_heap_finalize.c:430)
==3468==    by 0x139903: duk__free_run_finalizers (duk_heap_alloc.c:206)
==3468==  Block was alloc'd at
==3468==    at 0x4C2DBC5: calloc (vg_replace_malloc.c:711)
==3468==    by 0x18F787: image_new (image.c:69)
==3468==    by 0x1A98DB: screen_new (screen.c:100)
==3468==    by 0x111E9D: main (main.c:227)
==3468==
==3468== Invalid read of size 4
==3468==    at 0x1902ED: image_unref (image.c:272)
==3468==    by 0x1A9A64: screen_free (screen.c:145)
==3468==    by 0x112797: shutdown_engine (main.c:484)
==3468==    by 0x111BFD: main (main.c:167)
==3468==  Address 0x2a10e590 is 0 bytes inside a block of size 112 free'd
==3468==    at 0x4C2CDDB: free (vg_replace_malloc.c:530)
==3468==    by 0x190369: image_unref (image.c:282)
==3468==    by 0x1A81D2: js_Surface_finalize (pegasus.c:4095)
==3468==    by 0x149B46: duk__handle_call_inner (duk_js_call.c:1619)
==3468==    by 0x14906F: duk_handle_call_unprotected (duk_js_call.c:1149)
==3468==    by 0x1185B9: duk_call (duk_api_call.c:60)
==3468==    by 0x13A10B: duk__finalize_helper (duk_heap_finalize.c:368)
==3468==    by 0x14AAA4: duk__handle_safe_call_inner (duk_js_call.c:2131)
==3468==    by 0x14A91B: duk_handle_safe_call (duk_js_call.c:1972)
==3468==    by 0x118928: duk_safe_call (duk_api_call.c:228)
==3468==    by 0x13A18A: duk_heap_run_finalizer (duk_heap_finalize.c:430)
==3468==    by 0x139903: duk__free_run_finalizers (duk_heap_alloc.c:206)
==3468==  Block was alloc'd at
==3468==    at 0x4C2DBC5: calloc (vg_replace_malloc.c:711)
==3468==    by 0x18F787: image_new (image.c:69)
==3468==    by 0x1A98DB: screen_new (screen.c:100)
==3468==    by 0x111E9D: main (main.c:227)
==3468==
  • Last Edit: September 11, 2017, 03:46:59 am by Eggbertx