Oops -- removed the excessive check for shared object in the case
where we're merely converting it's internal rep.
On 11/15/06, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
[Switching to thread 5 (Thread -1471153248 (LWP 22074))]#0 0xb7f21410
in ?? ()
(gdb) bt
#0 0xb7f21410 in ?? ()
#1 0xa84fd3c
On 15.11.2006, at 18:48, Zoran Vasiljevic wrote:
Uhuhu... that's bad. Obviously the problem is deeper.
This might not be trivial. I wonder how it worked before?
Hm... one has to see wether this is really the wanted behaviour,
I mean to panic at that place. I can't tell more about it now
unles
On 15.11.2006, at 18:39, Vlad Seryakov wrote:
I see additional checks about Tcl time object being shared and
those are
trigger panics now.
Uhuhu... that's bad. Obviously the problem is deeper.
This might not be trivial. I wonder how it worked before?
I see additional checks about Tcl time object being shared and those are
trigger panics now.
Zoran Vasiljevic wrote:
On 15.11.2006, at 18:27, Vlad Seryakov wrote:
Now it is panicing all the time and i am using Tcl time calls only
This is most probably introduced in last 2-3 weeks as I have
On 15.11.2006, at 18:27, Vlad Seryakov wrote:
Now it is panicing all the time and i am using Tcl time calls only
This is most probably introduced in last 2-3 weeks as I have
not updated my copy since then and I do not experience any
such problems. I vaguely recall that I've seen Stephen chan
Now it is panicing all the time and i am using Tcl time calls only
Vlad Seryakov wrote:
[Switching to thread 5 (Thread -1471153248 (LWP 22074))]#0 0xb7f21410
in ?? ()
(gdb) bt
#0 0xb7f21410 in ?? ()
#1 0xa84fd3c8 in ?? ()
#2 0xb7d60ff4 in ?? () from /lib/libc.so.6
#3 0xa84fd3b4 in ?? ()
#4
[Switching to thread 5 (Thread -1471153248 (LWP 22074))]#0 0xb7f21410
in ?? ()
(gdb) bt
#0 0xb7f21410 in ?? ()
#1 0xa84fd3c8 in ?? ()
#2 0xb7d60ff4 in ?? () from /lib/libc.so.6
#3 0xa84fd3b4 in ?? ()
#4 0xb7ccf756 in __nanosleep_nocancel () from /lib/libc.so.6
#5 0xb7ccf548 in sleep () fro
