Look like that was it - thanks for everyone help!

On a completely unrelated topic:

Many of my users find it very hard to install emscripten, or to upgrade to
the latest version (1.37.9 here) for use with the transpiler.

I would therefore like to put together a little 'just works' single dir
package of the emscripten sdk/tools based on the portable version (if
that's stll around).

All I really need is em++, emar, and whatever it is they depend on (emld?
etc...ie: the bin dir?). Do I really need 'node.js', 'spidermonkey'
(whatever that is) and the other baggage? I realize I probably need python,
although I do provide my own server for hosting the 'apps' so don't
actually use it for that, so I'm not actually sure what it is for although
I gather python is generally how script-ish stuf works on all targets these
days?

Anyway, what can I leave out from a super simple, em++/emar  only style
standalone package?



On Mon, Dec 18, 2017 at 12:13 PM, András Kucsma <[email protected]>
wrote:

> Yes, definitely.
>
> You can also try setting -s SAFE_HEAP=1 to automatically assert on
> alignment and other memory access errors.
> https://kripken.github.io/emscripten-site/docs/porting/Debugging.html
>
> On Mon, Dec 18, 2017 at 12:01 AM, Mark Sibly <[email protected]>
> wrote:
>
>> Actually, think I know what's going on.
>>
>> I have a custom operator new() which does not necessarily return 8 byte
>> aligned memory (I think)?
>>
>>  Would this be enough to cause problems in asm.js but not in wasm?
>>
>>
>>
>> On Mon, Dec 18, 2017 at 10:58 AM, Mark Sibly <[email protected]>
>> wrote:
>>
>>> > what does the structure definition look like?
>>>
>>> Well, it's the output of a transpiler so it's a bit of a mess. But the
>>> basic idea is:
>>>
>>> struct GCNode{
>>> GCNode *succ,*pred;
>>> char pad[2];
>>> char state;
>>> char flags;
>>>
>>> virtual ~GCNode(){
>>> }
>>> };
>>>
>>> struct Timer : GCNode{
>>>
>>> Timer( double hertz ){
>>> period=1.0/hertz;
>>> }
>>>
>>> double period;
>>> };
>>>
>>> ...where 'Timer' is the user class causing problems and GCNode is a
>>> system class.
>>>
>>> When built by the transpiler, the end result is that the write to
>>> 'period' seems to be accidentally writing to 'state '- so it's possibly
>>> worth noting it's therefore not an asm.js alignment issue, the compiler is
>>> producing valid but incorrect code. However, if you build/run this as
>>> is, it works fine. I have only encountered the problem when running the
>>> output of the transpiler, and all attempts to c++-ify an example have
>>> failed so far. It's a real heisenbug!
>>>
>>> The 'period' field is indeed misligned for a double, as there is malloc
>>> size+virtual function table (8 bytes) at start of allocation. And adding an
>>> int 'pad' field just before 'period' fixes the problem.
>>>
>>> Could be the transpiler I guess, but I haven't had this issue with
>>> mingw32 or android/ios 32 bit builds - or even wasm. Just asm.js builds.
>>>
>>> On Mon, Dec 18, 2017 at 9:56 AM, Brion Vibber <[email protected]> wrote:
>>>
>>>> In asm.js code, all memory loads and stores must be aligned (wasm does
>>>> not have this limitation).
>>>>
>>>> Normally alignment rules on structs should 'just work' I think -- what
>>>> does the structure definition look like?
>>>>
>>>> -- brion
>>>>
>>>> On Dec 17, 2017 12:46 PM, "Mark Sibly" <[email protected]> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I am having some intermittent problems with what appears to be float
>>>>> point double alignment, where writing to a floating point double field 
>>>>> ends
>>>>> up writing to the wrong location. This has been solved in every case so 
>>>>> far
>>>>> by manually '8 byte aligning' the double field.
>>>>>
>>>>> Also, this only seems to be happening when generating asm.js 'apps' -
>>>>> so far, there have been no problems with wasm.
>>>>>
>>>>> Unfortunately, this is happening in a translator I am writing, and
>>>>> every attempt I have made so far to isolate some reproducable c++ code has
>>>>> failed!
>>>>>
>>>>> Just wondering of this was a known issue of some kind, or if anyone
>>>>> else has had similar problems? With a bit of luck I'll be able to retire
>>>>> the asm.js target soon in favour of wasm in which case it wont matter, but
>>>>> I just thought I'd check...
>>>>>
>>>>> Bye,
>>>>> Mark
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "emscripten-discuss" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to [email protected].
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>> --
>>>> You received this message because you are subscribed to a topic in the
>>>> Google Groups "emscripten-discuss" group.
>>>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>>>> pic/emscripten-discuss/l_P-aW8ZYm4/unsubscribe.
>>>> To unsubscribe from this group and all its topics, send an email to
>>>> [email protected].
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "emscripten-discuss" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/emscripten-discuss/l_P-aW8ZYm4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> [email protected].
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to