World: r3wp

I can confirm I've seen such a strange crash as well without any 
graphic involved.

Does it still crash with trace set on ?

I don't know... it was after some heavy real job made in console. 
I'm using R2 instead.. it's a little bit slower, but stable.

I had a couple of crashes that went away when I set trace on ...they 
were both on OS X and I think are related to memory issues. They 
are still open in CureCode.

I'm quite used to have several consoles opened which I use for multiple 
purposes and do not close them after each finished script. So I'm 
more affected by these possible GC bugs in R3.

Sadly, it doesn't help with debugging.

Sadly, debugging does not help if nobody is interested.

True.

One nasty crash seems to be located in RESOLVE (cc#1865), which basically 
makes almost all module-system related stuff unstable/crashy.

Basically, everywhere you use IMPORT you could be affected by this 
bug.

I can assure you that there is a bug in Resolve.

We should probably buy a radio, and contact Carl on Mendoradio :-)

The module system can be fixed to not use RESOLVE/extend/only, and 
a few months ago I submitted such a fix to Saphiron for them to include 
in their next host code release, along with other mezzanine fixes. 
I'm just waiting for them to post another release. In the meanwhile, 
in my own module code that does exports I do the exports explicitly 
in the module code itself instead of using the EXPORT keyword or 
the Exports header.

Afaik, we (the community, that includes Saphirion) cannot build binaries 
incorporating mezzanine changes with the current hostkit.

Nope, you just can't build a single binary with a statically linked 
r3lib. You can build a host kit exe with a dynamically linked r3lib 
with any mezz changes you want.

Nope, the current hostkit build does not take mezz changes into account 
in any way.

Interesting. I thought that the mezzanines were loaded by the host, 
not built into r3lib.

Some of them are (mostly the bundled extension related ones), most 
of them are not.

(See %src/tools/make-host-{init,ext}.r for details.)

If I make a patch file that fixes the mezz problems, including the 
module-related ones, will that work? For now (when the module list 
isn't really protected yet) this is doable...

We can't hot-patch functions in R3 for security reasons, but we can 
replace them completely with fixed versions.

When would you load that patch file?

I think you mentioned somewhere, that replacing affected functions 
from user.r is not possible.

(For this particular RESOLVE issue.)

I load a patch file in %rebol.r right now, for my work use of R3. 
If I was doing my own host builds then I would put a reference to 
the patch file early on in the host-init code.

%rebol.r still works, and it loads pretty early on in the boot process. 
The host init loads earlier.

I don't have the loading intricacies in enough detail in my head 
right now to reason about this sensibly.

But I guess we could at least try, if you have a particular hotfix 
in mind.

I have a list of fixes and improvements in mind, so I'll see if there's 
some time by the end of this week to put together a patch file. I'm 
sorry that I haven't documented the module system well enough to 
make it practical for anyone other than me to patch it at runtime. 
Improving its documentation is on my todo list, though I've been 
a bit busy at work lately.

Hopefully this patch file will serve as an example for others who 
want to do similar patching.

I succesfully 'overloaded' some mezz functions in R3 in the RMA hostkit. 
See the inclusion of %rma-patches.r file in src\tools\make-host-init.r 
in the RMA host-kit release. So it is possible to do some fixes that 
way.(of course not every part can be tweaked such way)