On Sunday, January 10, 2016 at 11:14:23 AM UTC+8, mflatt wrote:
>
> At Sat, 9 Jan 2016 18:58:19 -0800 (PST), Alex Harsanyi wrote: 
> > When using Racket 6.3.0.11 (built on 2016-01-06) and your recommended 
> > changes to calling create-embedded-executable, I get a built 
> > application that starts up in the same amount of time as the one 
> > built with 6.1.1. Unfortunately, the memory use while compiling is 
> > still high: seems to me to be about the same as for 6.3, but I'm only 
> > watching the number in the task manager. Incidentally, because it 
> > uses about 3Gb of ram, the build is constantly swapping, making it 
> > extremely slow. 
>
> The TR team is working on performance improvements in the TR compiler 
> and the comple-time information it generates, and there's also room for 
> improvement in the way that `raco exe` works. Unfortunately, though, my 
> guess is that it will be a while before build times improve for your 
> application. 
>

Thanks for working on it.
 

>
> > On a somewhat related note, there are two additional issues I noticed 
> with 
> > the executables produced by the Racket compiler (across several Racket 
> > versions, but also present in the last pre-release build). 
> > 
> > First problem is that although the compilation succeeds with no error 
> > message, the application fails to run with a message like: 
> > 
> > link: bad variable linkage; 
>
> Does that still happen with the extra `parameterize` that I suggested 
> previously? If so, probably DrRacket is influencing 
> `create-embedding-executable` in some other way that I didn't notice. 
>

No, it did not.  However, at least with racket 6.1.1 this type of problem 
was hard to reproduce, but  I commited the change to the code base and will 
monitor if this is happening in the future.
 

>
> > Second, the resulting application seg-faults, sometimes at startup 
> > sometimes during importing sport activties.  I have the crash dumps but 
> > cannot make any sense of them, as I have no PDB's for libracket and I'm 
> not 
> > familiar with the internals.  If you are interested, I can make them 
> > available. 
>
> Any information you have would be useful. If there's some way I can run 
> the application to reliably trigger a crash, that would also be useful. 
>

Unfortunately  I don't have a reliable way to trigger a crash.  There are 
two situations when a crash happens: at startup -- this happens a few times 
a week (I use this application daily), just as I start the application.  
The second type of crash is  just after importing some fitness activities 
-- this is more rare.  In both cases the application crashes at system 
level (no Racket exception is thrown).

I put some crash dumps here:

https://drive.google.com/folderview?id=0B5h4XOdkim72eVdqRnY5MWNoUUU&usp=sharing

The first crash is:

Unhandled exception at 0x00007FFE8DD2324A (ntdll.dll) in ActivityLog2.dmp: 
0xC0150014: The activation context activation stack for the running thread 
of execution is corrupt (parameters: 0x0000000000A00830, 
0x0000000000846270, 0x0000000000846270, 0x000000001B6ED300).

Call stack is:
     ntdll.dll!RtlActivateActivationContextUnsafeFast()    Unknown
     user32.dll!UserCallWinProcCheckWow ()    Unknown
     user32.dll!DispatchMessageWorker ()    Unknown
     libracket3m_9xtjc8.dll!000000018033bc43()    Unknown
     libracket3m_9xtjc8.dll!000000018000165f()    Unknown
     libracket3m_9xtjc8.dll!0000000180018448()    Unknown
     libracket3m_9xtjc8.dll!0000000180018679()    Unknown

The second crash type is an access violation (segfault).

I 'm thinking of adding some logging to the code to try to determine what  
Racket code is running when the crash happens. Are there some 
recommendations on how to debug these types of crashes?  Is there a way to 
map from a crash dump location to the running Racket code?

Best Regards,
Alex.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-dev/c16a9445-b64d-4d01-a216-519df395c65f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to