On Mon, 2004-01-19 at 04:11, Leopold Toetsch wrote:
> Harry, do you still see these hanging parrot programs?
> chromatic, do you run a DeadRat (sorry) linux too?
Nope, none here. I can try a different pthread library though.
-- c
Leopold Toetsch wrote:
Harry Jackson <[EMAIL PROTECTED]> wrote:
RHAS 2.1 dev edition
Harry, do you still see these hanging parrot programs?
chromatic, do you run a DeadRat (sorry) linux too?
RedHat is well known to provide b0rken patches to otherwise running
software. Could you try to up/down/s
Harry Jackson <[EMAIL PROTECTED]> wrote:
> RHAS 2.1 dev edition
Harry, do you still see these hanging parrot programs?
chromatic, do you run a DeadRat (sorry) linux too?
RedHat is well known to provide b0rken patches to otherwise running
software. Could you try to up/down/side-grade *libpthread*
Chromatic <[EMAIL PROTECTED]> wrote:
> (gdb) bac
This is the main thread, that has suspended itself during exit
processing.
> #0 0x0ff976a4 in __pthread_sigsuspend () from /lib/libpthread.so.0
...
> #3 0x0fd0a694 in exit () from /lib/libc.so.6
> (gdb) thread 2
That's the thread-manager thread
On Sat, 2004-01-17 at 12:12, Leopold Toetsch wrote:
> But I'm a bit worried about the reason, why it actually hangs here:
>
> > (gdb) bac
> > #0 0x0ff976a4 in __pthread_sigsuspend () from /lib/libpthread.so.0
> ...
> > #3 0x0fd0a694 in exit () from /lib/libc.so.6
> > #4 0x0fcf23a8 in __libc_st
Chromatic <[EMAIL PROTECTED]> wrote:
> On Sat, 2004-01-17 at 04:29, Leopold Toetsch wrote:
>> I've converted this exit() to Parrot_exit() now. If that helps, I'll
>> change a bunch of other such code too.
> Yep, that fixed. Now there are hangs in some of the t/src files. Right
> now, it's t/src
On Sat, 2004-01-17 at 04:29, Leopold Toetsch wrote:
> I've converted this exit() to Parrot_exit() now. If that helps, I'll
> change a bunch of other such code too.
Yep, that fixed. Now there are hangs in some of the t/src files. Right
now, it's t/src/sprintf.t at test 2. The backtrace looks fa
Chromatic <[EMAIL PROTECTED]> wrote:
> This gets further. Now it's imcc/t/syn/macro, around tests 13 and 14:
Good.
> #3 0x0fd0a694 in exit () from /lib/libc.so.6
I've converted this exit() to Parrot_exit() now. If that helps, I'll
change a bunch of other such code too.
leo
On Fri, 2004-01-16 at 12:42, Leopold Toetsch wrote:
> Ah yep. When committing the first (trial) fix, I thought about such
> a problem, which is related:
> - if it seems to hang on a condition variable (still AFAIK: it shouldn't)
It reminds me of a problem I'm having with MySQL, actually.
> - b
Chromatic <[EMAIL PROTECTED]> wrote:
> Yes, that's better. (Upgrading glibc didn't help -- I was worried that
> this was an NPTL issue that Parrot couldn't fix.)
Cool.
> Now it hangs on t/pmc/timer:
> 0x10090b30 in Parrot_del_timer_event (interpreter=0x10273e88,
Ah yep. When committing the fi
On Fri, 2004-01-16 at 01:07, Leopold Toetsch wrote:
> I've checked in now:
>
> * terminate the even loop thread on destroying of the last interp
> * this could help against the spurious hangs reported on p6i
>
> Could you please check if that helps.
Yes, that's better. (Upgrading glibc didn't
Chromatic <[EMAIL PROTECTED]> wrote:
> This time, it's hanging at t/op/00ff-dos.t:
I've checked in now:
* terminate the even loop thread on destroying of the last interp
* this could help against the spurious hangs reported on p6i
Could you please check if that helps.
Thanks,
leo
Chromatic <[EMAIL PROTECTED]> wrote:
> On Thu, 2004-01-15 at 23:26, Leopold Toetsch wrote:
>> Could you attach gdb to the hanging parrot?
> This time, it's hanging at t/op/00ff-dos.t:
> (gdb) bac
> #0 0x0fd0e600 in sigsuspend () from /lib/libc.so.6
> #1 0x0ff970ac in __pthread_wait_for_restart
On Jan 15, 2004, at 10:42 PM, chromatic wrote:
On Sun, 2004-01-04 at 12:09, Harry Jackson wrote:
I tried that as well, it spits out identical PASM each time but on the
odd occasion I need to use CTRL-C to get back to the shell.
I'm seeing the same thing on Linux PPC -- odd hangs from time to time
On Thu, 2004-01-15 at 23:26, Leopold Toetsch wrote:
> Could you attach gdb to the hanging parrot?
This time, it's hanging at t/op/00ff-dos.t:
(gdb) bac
#0 0x0fd0e600 in sigsuspend () from /lib/libc.so.6
#1 0x0ff970ac in __pthread_wait_for_restart_signal ()
from /lib/libpthread.so.0
#2 0x0f
Chromatic <[EMAIL PROTECTED]> wrote:
> On Sun, 2004-01-04 at 12:09, Harry Jackson wrote:
>> I tried that as well, it spits out identical PASM each time but on the
>> odd occasion I need to use CTRL-C to get back to the shell.
> I'm seeing the same thing on Linux PPC -- odd hangs from time to time
On Sun, 2004-01-04 at 12:09, Harry Jackson wrote:
> I tried that as well, it spits out identical PASM each time but on the
> odd occasion I need to use CTRL-C to get back to the shell.
I'm seeing the same thing on Linux PPC -- odd hangs from time to time
when running PIR, while running the PASM
Leopold Toetsch wrote:
Harry Jackson <[EMAIL PROTECTED]> wrote:
Can someone tell me if there is an error in the code below.
The code is fine.
it repeatedly from the command line it sometimes freezes ie it prints
the contents of the array and then just stops and I need to do a CTRL-C
to get ba
Harry Jackson <[EMAIL PROTECTED]> wrote:
> Can someone tell me if there is an error in the code below.
The code is fine.
> it repeatedly from the command line it sometimes freezes ie it prints
> the contents of the array and then just stops and I need to do a CTRL-C
> to get back to the command
Dan Sugalski wrote:
Let us know either way -- if upgrading gcc works then we're going to
have to figure out how RH/GCC2.96 is breaking things so we can make it
not happen. :(
I have now upgraded gcc to 3.3.2 and I am getting the same error. We are
still freezing during test.
I have also noticed
At 11:52 AM + 1/2/04, Harry Jackson wrote:
Dan Sugalski wrote:
[EMAIL PROTECTED] pbin]$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 2731 (Red Hat Linux 7.2 2.96-108.1)
Yeah, that was the one, unfortunately. Try disabling the JIT during
configu
Dan Sugalski wrote:
[EMAIL PROTECTED] pbin]$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 2731 (Red Hat Linux 7.2 2.96-108.1)
Yeah, that was the one, unfortunately. Try disabling the JIT during
configuration and seeing if that takes care of the pro
At 12:34 AM + 1/2/04, Harry Jackson wrote:
Dan Sugalski wrote:
Just out of curiosity... what version of gcc are you running? We
were having no end of problems with the JIT and one of the mutant
versions of 2.95 that redhat was packaging up at one point.
[EMAIL PROTECTED] pbin]$ gcc -v
Reading
Dan Sugalski wrote:
Just out of curiosity... what version of gcc are you running? We were
having no end of problems with the JIT and one of the mutant versions of
2.95 that redhat was packaging up at one point.
[EMAIL PROTECTED] pbin]$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/
At 11:29 PM + 1/1/04, Harry Jackson wrote:
Leopold Toetsch wrote:
Do you have a SMP machine with SMP enabled in your OS?
The unpredictable behavior of your freezes makes me think, that it could
be related to multi-threading. OTOH arithmetic tests or such don't
utilize threads and no events are
On Dec 30, 2003, at 5:19 PM, Harry Jackson wrote:
I have also tried strace and got the following.
Try this on parrot rather than Perl.
strace on parrot gets to
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
wait4(-1, [WIFEXITED(s) && WEXITSTATUS(s) == 0], 0, NULL) = 8423
--- SIGCHLD (Child exited)
Leopold Toetsch wrote:
Do you have a SMP machine with SMP enabled in your OS?
The unpredictable behavior of your freezes makes me think, that it could
be related to multi-threading. OTOH arithmetic tests or such don't
utilize threads and no events are being generated.
I am running a Cray X1 ( I wis
Harry Jackson <[EMAIL PROTECTED]> wrote:
> It gets even stranger. If I do a make clean and make test again it does
> not necessarily stop in the same place each time ie.
Do you have a SMP machine with SMP enabled in your OS?
The unpredictable behavior of your freezes makes me think, that it could
Jeff Clites wrote:
On Dec 30, 2003, at 3:11 PM, Harry Jackson wrote:
2) Try running one of the tests which blocks, individually. If you
can get it to happen this way, then run it in gdb and see what it's
doing. (Or, attach to an already blocked one from 'make test'--this
is assuming it's parrot
On Dec 30, 2003, at 3:11 PM, Harry Jackson wrote:
2) Try running one of the tests which blocks, individually. If you
can get it to happen this way, then run it in gdb and see what it's
doing. (Or, attach to an already blocked one from 'make test'--this
is assuming it's parrot that's actually bl
Jeff Clites wrote:
Here are 3 things to try:
1) When it hangs there, check with 'top' to see if it is using CPU (ie,
is it blocking, or in an infinite loop).
Already done that and it is eating no cycles.
2) Try running one of the tests which blocks, individually. If you can
get it to happen th
On Dec 29, 2003, at 2:12 PM, Harry Jackson wrote:
During
[EMAIL PROTECTED] parrot]$ make test
echo imcc/imcc.y -d -o imcc/imcparser.c
imcc/imcc.y -d -o imcc/imcparser.c
perl -e 'open(A,qq{>>$_}) or die foreach @ARGV' imcc/imcc.y.flag
imcc/imcparser.c imcc/imcparser.h
perl t/harness --gc-debug --
During
[EMAIL PROTECTED] parrot]$ make test
echo imcc/imcc.y -d -o imcc/imcparser.c
imcc/imcc.y -d -o imcc/imcparser.c
perl -e 'open(A,qq{>>$_}) or die foreach @ARGV' imcc/imcc.y.flag
imcc/imcparser.c imcc/imcparser.h
perl t/harness --gc-debug --running-make-test -b t/op/*.t t/pmc/*.t
t/native_
33 matches
Mail list logo
