Skip to main content ↑ ↓
Topic: neoSphere 5.10.1 (Read 8505830 times) previous topic - next topic
0 Members and 7 Guests are viewing this topic.

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.

Re: miniSphere 4.8.5

Reply #2086 –
Quote from: DaVince – on
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.

Re: miniSphere 4.8.5

Reply #2087 –
Quote from: DaVince – on
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 :(

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.

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.

Re: miniSphere 4.8.5

Reply #2090 –
Quote from: Fat Cerberus – on
Quote from: DaVince – on
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.

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

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. ;)

Re: miniSphere 4.8.4

Reply #2093 –
Quote from: Eggbertx – on
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?

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?

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. ;)

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

Re: miniSphere 4.8.5

Reply #2097 –
Quote from: DaVince – on
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 :)

Re: miniSphere 4.8.5

Reply #2098 –
Quote from: DaVince – on
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.

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==