World: r3wp

Not gone entirely, but happens far less frequenty.

Which makes it hard to debug. Very deeply nested blocks with many 
inserts and removes can trigger it.

I see. Unfortunately it seems I hit it close to every time I do a 
specific operation, but I have no time to debug it...

It's annoying!

Sometimes just moving code around can fix it. Try making some local 
words global, for example.

it's actually a showstopper for me and exactly this code needs to 
be working in front of a customer in about 5 hours....

I think it would be good to have an example with this bug for sending 
it to Carl

the thing is that its db synchronization code (I'll think out loud 
here) and it's used in 5-6 different places. only in one place does 
it crash.

it seems to be accumulative, since it does not happen in exactly 
the same spot every tine and is possibly related to Rugby's do-every 
function, because it seems to happen whenever the do-every is executed.

To tell the truth, I don't know what I did with previous versions 
that actually worked. But doing *something* that affected garbage 
colection seemd to move the bug around. eg
-- global words not local words
-- xx: make block! 1000 not  xx: copy []

http://rebol.hmkdesign.dk/db-sync.r<-- the db sync code is here.

sunanda, repeated clears of a block perhaps?

I had adopted the techinque of clearing a block before reusage instead 
of using a new make block! [] Maybe that's a bad idea.

Clear -- It's probably a good idea for this reason: the block will 
grow to its maximum size after repeated uses, and so saves time in 
memory allocation / block extension.
May be a bad idea if that max size is causing problems :-)

allocated 100000 to the first block in the code and it's still running...

Let's hope that gets you through the demo....Good luck!

it crashed again :-(

I think I'll panic and allocate 100000 elements to every single block 
in the database

i had such a problem with massive gui and async. Workarounded the 
following way: recycle is off permanently. there is a thread (do-every 
or such) which checks how much memory was allocated and when it is 
to much it recycled. crashing stopped.

you may try  recycle/off   and do it yourself

:)

;like

if 20 * 1000 * 1000 + stats > last-mem [  recycle .  last-mem: stats 
]
;and that every 0.01 second or so.

anyway.... using   make block! []  is quite useless

allocating 100000 elements for each block will slow down performance 
too much I guess

Its only for demo, and 3:30 left. better waste memory than a contract..

with recycle forced off, it seems to be running OK for now

just make sure you recycle sometimes... if it's long running process

it will not run more than 2-3 hours today :-)

ok, it ran perfectly. the demo was approved and the product goes 
live on Wednesday.

Good news!
So you have a few days to fix the recycle problem for real :-)

actually I'm going to look at a printerserver, which deadlocks, if 
two people are trying to print too close to eachother.

it's quite simple, I think it was based on some cookbook code. moving 
to ports for that...

this is an annoyance ... but 'to-local-file drops the trailing slash 
for directories

confirmed under OSX

Rambo it ??

yep

Ok

it's not a problem the other way around, so yes, it's inconsistent.

Done.

Henrik, I see regular "Crash Should not happen" on one of my scripts, 
so you are not alone.

anyone willing to find a way to reproduce it?

I don't have anything trivial that will trigger the bug. It's a big 
application that can run for a while before crashing....And the code 
has been tweaked to minimise the occurrence of the problem.

i feel the pain - same problem i had with chord.

but at this point (focused on R3) RT does not have enough resources 
to debug a big app.

well, if it's about memory allocation and clean up, would there not 
be a way to torture it? What's the worst possible way to stress the 
garbage collector?

recycle/torture

but i guess it won't show in that case...

something that randomly creates a large amount of blocks, inserts, 
deletes, manipulates, copies and does various other things.

just found, that youtube do not respect HTTP1.0 protocol => sends 
HTTP1.1 303 response even if client require HTTP1.0 (which is Rebol 
case). As there is no response specified for 303 in Rebol's http 
handler, it can be fixed using:

use [tmp][

 tmp: select second get in system/schemes/http/handler 'open to-set-word 
 'response-actions
	if none? find tmp 303
	insert tmp reduce [303 select tmp 302]
]

whith the patch above you should be able to do for example:

trace/net on

p: open/direct http://www.youtube.com/get_video?video_id=FVbf9tOGwno&t=OEgsToPDskKR0Ng6kANs3Z4VNG81T2tZ
error? try [close p]

(Reichard: will be fixed the Altme bug which cripples text with long 
links?)

it should be easy imho