[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]
tentative bug report about difficult-to-reproduce but substantial problems with 5.005_6x
I dropped a not-so-well-though comment in a conversation with ilya, and he
thought it might be a good idea to post my explanations here.
The observations below are very vague, and might not really be perl bugs,
but I continue to rule out other possible reasons, so it might be helpful
for you to know that _I_ encounter big problems with perl5_005_6x and a
variety of modules, especially larger ones like SDF and gimp-perl.
HTH, if not, I still try to find a small enough testcase.
I might also add that, while I compiled perl once with 2.7.2.3 (and got
a problem), most of my epxlanations refer to my developer machine, which
is a linux-2.2/x86 machine with gcc-2.95.2 (and pgcc-2.95.2). I do not
encounter any similar problems with 5.005_03 using the same system&perl
configuration.
----- Forwarded message from Marc Lehmann <marc@gimp.org> -----
On Sat, Jan 08, 2000 at 12:39:23AM -0500, Ilya Zakharevich <ilya@math.ohio-state.edu> wrote:
> > Oh :( That's the price I had to pay for downgrading from _6x (which break
> > almost every module on the planet ;->
>
> Can you be more concrete? This is the first time I've heard about this...
You know, I usually try to send something that one can use to _reproduce_ the
bug.
The problem is that all the bugs I encounter are indeed reproducable, but
they require quite an elaborate setup and _many_ lines of code.
For example, in gimp-perl, I try (without much success of course) to catch
errors and warnings from die and warn in the die/warn "signal handler". I
also use die (and croak via xs) as an exception mechanism.
This all works fine (modulo that errors during eval parsing are wrongly
being reported as bugs in the program, while "eval" execution is properly
signaled) on 5.005_03.
With (any!) 5.005_6x I sometimes get mysterious segfaults, sometimes I just
get empty error mssages (and I don't know where they get lost: printing or
storing the message in my signal handler sometimes 'fixes' this).
Sometimes a croak from xs creates a silent exit(!) or a segfault (without
usable backtrace).
All this is very difficult to debug, since it could just be errors in my
xs modules (mortality or something).
I also encounter problems with PDL. For example:
$a = zeroes 500;
$b = zeroes 300;
$c = cat $a, $b
always works. But
$c = cat zeroes(500), zeroes 300
Also works in a subroutine. But when I return this at the end, the caller
seems to only receive an undefined value.
What's worse: this does not happen in any 3 lines example.
Next module: SDF. When I use it with 5.005_63 (the last I tried with it), it
just works for some time, but it outputs "human readable garbage", i.e. like
==============================================================
[tuning ...xxxx]
=head2 Header
==============================================================
Instead of the correct html or pod output.
Sooooo..... while it pretty much breaks any larger module I happen to
_use_, I haven't yet succeeded in producing anything that is small enough
to be mailed (single file for example), which is why I planned to be quiet
until either I can find a testcase or until it is going to be released ;)
I just couldn't resist dropping you my general feelings. I followed
5.004_50+ all the time, and never experienced such problems. They started
somewhere around 5.005_60 or _61 and are very complex. I originally thought
that I had a bug somewhere (and indeed I found quite many ;), but since other
modules (even perl-only like SDF) have similar unexplainable bugs.
I also thought about the compiler being the problem, but neither
gcc-2.95.2 or 2.7.2.3(!!) made any difference.
> Well, Nick complained about Tk, but I thought I sent patches to fix this.
If you meant the arguments gets lost patch that you sent: it doesn't
help. I thought it would since it's description is very close to what I
encounter with PDL, but it didn't help.
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@opengroup.org |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
----- End forwarded message -----
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@opengroup.org |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]