r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[RAMBO] The REBOL bug and enhancement database

Anton
10-Jul-2005
[890]
Gabriele, can you add an extra bit to the details here http://www.rebol.net/cgi-bin/rambo.r?id=3837&

A reason for wanting this is to be able to generate an image of what 
the style looks like without opening a window, eg. for documentation.

(It's good to see what the original reasons are for each bug report. 
Should make fixing them more satisfying too.)
Henrik
10-Jul-2005
[891x2]
volker, well I didn't get any trouble under Linux with GNUstep's 
Terminal.app so it may be a terminal issue
If I ssh to a linux box from the terminal where I saw the problem 
originally, there is no problem either
Anton
13-Jul-2005
[893x2]
Gabriele, I have some additional information for a ticket:
http://www.rebol.net/cgi-bin/rambo.r?id=3314&


Memory usage climbs, but there is no longer any crash on View 1.3.1

i: 0 until [
	attempt [
		view layout [
		button feel [
		redraw: func [face action pos][
		;if action = 'draw [show face] ; memory use climbs very high
		if action = 'show [show face]  ; memory use looks quite stable
		]
		]
		]
	]
	1000 <= i: i + 1
]
unview
Gabriele
13-Jul-2005
[895]
hmm, need to check all tickets with undetermined importance. otherwise 
they get overlooked.
Anton
14-Jul-2005
[896]
view/new win: layout [] win/changes: reduce [:+] show win  ; crash
Henrik
14-Jul-2005
[897]
anton: confirmed
Anton
14-Jul-2005
[898x3]
Thanks Henrik. You can also try putting different functions, natives, 
ops, in there for the same result. (I haven't tried them all, though.)
none does not cause a crash, though.
I have searched for "changes" in rambo and I did not find a similar 
ticket.
Gabriele
14-Jul-2005
[901]
add it :)
Anton
14-Jul-2005
[902]
OK done. :)
Ladislav
17-Jul-2005
[903x2]
Hi, #3545 is marked as High importance. Actually, it is underestimated, 
because such problems are critical even for pre-alpha Rebol programs 
e.g. when trying to send keep-alive type messages to a port using 
Romano's ATCP scheme. I  wonder what is an optimal work-around for 
the current (Core 2.6 - based) scripts? (see #3465 too, marked - 
underestimatedly - as Medium importance) .
(I know, that we can use Timers for View scripts, but that does not 
solve the Core case)
Gabriele
18-Jul-2005
[905x3]
timeouts are a problem for normal (non-async) core, but should work 
fine on async core.
the "solution" (a trick, with its own problems...) i use for the 
detective is http://www.colellachiara.com/soft/Libs/timers.r
anyway - this is something we *need* for /services... so i guess 
there will be a real solution very soon.
sqlab
18-Jul-2005
[908]
just a few weeks ago I wrote that with the new rebcmd for Win my 
problems with odbc and catch were gone.

Now I encountered a "Crash, should not happen" with a script doing 
not more than receiving data from tcp sockets, parsing the data, 
writing to files and sending a response back.

Some almost identical scripts were working with the old cmd for months 
without interruption.
JaimeVargas
18-Jul-2005
[909]
Can you isolate the problem?
sqlab
18-Jul-2005
[910]
I will try, but I am not very optimistic
sqlab
20-Jul-2005
[911]
It's reproducible
Crash (should not happen) invalid string width 16: type 41
sqlab
21-Jul-2005
[912]
Now I get the crash every second day
JaimeVargas
21-Jul-2005
[913]
Isolation is key to fix the problem. If you can't isolated it, please 
post the full script.
sqlab
21-Jul-2005
[914x3]
I can see where the crash happens.

It happens in or just before an awake function, when the peer closes 
the socket.


On_Data: func [port] [action-time: now con: port msg: copy: copy 
port 
	if any [none? msg empty? msg] [print ... 

and the print is not evaluated.
The script alone will probably not help you, as you will need the 
data too.
Maybe there is data also coming from a second port, as I have sometimes 
seen a crosstalk of events, if there is heavy traffic on the pc.
Gabriele
21-Jul-2005
[917]
does it have a GUI too?
sqlab
21-Jul-2005
[918]
no, just a plain console application accepting tcp socket connections 
and data
Gabriele
21-Jul-2005
[919]
is it doing anything woth noting during the awake? creating objects, 
or something like that?
sqlab
22-Jul-2005
[920]
When accepting a new connection, a new object is created.

After accepting new data there is mainly parsing, block and string 
creating, writing to the console and to files and sending a reply 
back
Gabriele
22-Jul-2005
[921]
did you check any other versions of command? (this is on the latest 
version, right?)
sqlab
22-Jul-2005
[922]
I did not see this with rebcmd2..55.3.1.alpha, but maybe I did not 
test with enough traffic from more than one sender at the same time.

I just remember that some of the interim releases were not stable 
enough regarding read/lines, so I was waiting for a (near) final 
release for intensive testing.


Now I am checking, if different behaviour of the sender has some 
influence.

Normally at least one sender establishes a permanent connection, 
but most sender open a connection, do their communication  and close 
the socket at the end.

That's the reason, why I know, that the crash happens after closing 
the socket.  The last message was always from one of the senders 
with a one time connection. He got his answer, but the receiver did 
not print the message, that the remote socket was closed.

Maybe it has to do with timing and or GC problems, as the crash happens 
mostly at a time, when there is more traffic, but never when there 
is always  continuous communication. When I play back the communication 
without interruption, there is no crash.
Gabriele
22-Jul-2005
[923]
my guess is that this will be very hard to figure out. please post 
all the info you can in a rambo ticket, then let's hope Carl will 
guess where the problem is. :)
JaimeVargas
22-Jul-2005
[924x2]
sqlab it will be good if you can do some pkt traces. Then later we 
can do some pkt replays to repeat the problem, and track it. We will 
need basically the server code. The client can be performed by the 
replay utility.
Server code and pkt capture. (pcap format is preferred this is done 
with ethereal).
sqlab
25-Jul-2005
[926]
Jaime: That will not be possible, as the data are subject to privacy.

i will try to narrow down the server and see if i can produce a crash 
with anonimized data.
sorry.(
Anton
26-Jul-2005
[927x3]
Right that does it. Feel/over is not always doing its documented 
job. "The over function is called whenever the mouse pointer passes 
over or off of a face."  (quote from http://www.rebol.com/docs/view-system.html
   )
view make face [offset: 100x100 pane: make face [feel: probe make 
face/feel [over: func [face action pos][probe action]]]]
The above example works but no longer works if you click and drag 
off the face.
JaimeVargas
26-Jul-2005
[930]
sqlab "anonimized data could work". We need to isolate the problem, 
and we all want a very robust rebol.
Anton
26-Jul-2005
[931x2]
So I will submit a bug report for that.

Also, I would like modifications to related ticket #3112 "How feel/over 
handles face vs subfaces":

- Type: should be changed from "Issue" -> "Bug"  (because I think 
it will be ignored otherwise)

- Importance: should be changed from "Undetermined" -> "Medium" at 
least.
Submitted the bug report.
Gabriele
26-Jul-2005
[933]
click and drag off
 -> that's the away action for the engage function.
Anton
26-Jul-2005
[934x2]
OK, so the above document needs to be changed to say something like: 
"... and not in the middle of a drag, whose events can be trapped 
with the engage function..."  ?
Thanks Gabriele, I am going to investigate some more. Perhaps you 
can add a comment to the report to change the doc instead (or at 
least).
Gregg
26-Jul-2005
[936]
In the works Anton. Thanks!
Anton
26-Jul-2005
[937]
Thank you, Gregg.
Graham
26-Jul-2005
[938x2]
well, the new rebcommand finally crashed on me too though took much 
longer than previously.  Usage jumped to 50% as before and stayed 
there.  I guess on a non hyperthreaded cpu, it would have jumped 
to 100%.
It's looking like I need to ditch odbc and move to using doc's mysql 
instead.