Re: xine, ppc and illegal instructions

Re: xine, ppc and illegal instructions

[Franz Sirl]

At 07:30 27.03.2001, Bill Fink wrote:
>         *  In configure, there's a case check for "powerpc-*-linux*)".
>            This should be changed to "powerpc-*-linux* | ppc-*-linux*)".

This isn't correct, it's always powerpc-*-linux*, the other one is
superflous. This usually happens if people didn't update their configure
scripts for a _long_ time and your patch is just papering over that.

Franz.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: xine, ppc and illegal instructions

[Bill Fink]

Some further investigation on my part and a question for Franz Sirl:

I updated to the latest Paulus rsync kernel (2.4.3-pre8) and the
latest gcc (2.95.3-2v) and 2.1 glibc (glibc-2.1.3-15g) from Franz,
but unfortunately none of this helps.  xine 0.4.01 still gets
illegal instructions (sometimes it gets a segmentation fault
instead).  No core dump is produced and it runs basically OK
when run under control of gdb, so it makes tracking down the
problem very difficult.

>From debug printout, it appears that it is dying in a call to dlopen,
which is in libdl, which is part of glibc.  Here's the tail end of an
strace of a xine run:

open("/usr/local/install/xine-0.4.01/lib/xine/plugins", O_RDONLY|O_NONBLOCK|O_DI
RECTORY) = 7
fstat(7, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
fcntl(7, F_SETFD, FD_CLOEXEC)           = 0
lseek(7, 0, SEEK_CUR)                   = 0
getdents(7, /* 12 entries */, 2980)     = 284
open("/usr/local/install/xine-0.4.01/lib/xine/plugins/input_file.so", O_RDONLY)
= 8
fstat(8, {st_mode=S_IFREG|0755, st_size=17054, ...}) = 0
read(8, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\0\t"..., 4096) = 409
6
mmap(0xfa28000, 70000, PROT_READ|PROT_EXEC, MAP_PRIVATE, 8, 0) = 0xfa28000
mprotect(0xfa29000, 65904, PROT_NONE)   = 0
mmap(0xfa38000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 8,
0) = 0xfa38000
close(8)                                = 0
mprotect(0xfa28000, 4096, PROT_READ|PROT_WRITE) = 0
mprotect(0xfa28000, 4096, PROT_READ|PROT_EXEC) = 0
--- SIGILL (Illegal instruction) ---
+++ killed by SIGILL +++

Given that the last system call was an mprotect, I searched the archives
and discovered that Olaf Hering reported a problem with mprotect on
January 23 on the linuxppc-dev list, see:

http://lists.linuxppc.org/listarcs/linuxppc-dev/200101/msg00324.html

Olaf provided a patch to fix the problem, which I wasn't totally clear
exactly what it was against, but I'm assuming it was glibc (I've never
looked at the glibc source).  Assuming it was a glibc patch, it wouldn't
be in the glibc-2.1.3-15g I downloaded since that was dated January 14.

Now my question for Franz.  Do you think the problem/patch reported
by Olaf is likely related to the apparent dlopen/mprotect problem I'm
having with the 0.4.01 version of xine (note the 0.3.7 version works
fine)?  Or could it possibly be hardware related?  I'm running on a
G4 which has Altivec, while Henry's system is a G3 IIRC, which I believe
doesn't have Altivec (or some other hardware difference).

I've pulled down the source for glibc-2.1.3-15g, but before I actually
try rebuilding it on my system (with or without Olaf's patch), I'd
appreciate some expert advice about whether it's worth the effort or
likely to have any effect.

						-Thanks

						-Bill


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: xine, ppc and illegal instructions

[Michel Dänzer]

Bill Fink wrote:

> I updated to the latest Paulus rsync kernel (2.4.3-pre8) and the
> latest gcc (2.95.3-2v) and 2.1 glibc (glibc-2.1.3-15g) from Franz,
> but unfortunately none of this helps.  xine 0.4.01 still gets
> illegal instructions (sometimes it gets a segmentation fault
> instead).

Have you tried other kernels? A lot of people including me have experienced
sporadic signals, most often with ldconfig, with Paulus' tree. I'm running
BenH's tree now and haven't seen it yet.

This is not to call Paulus' tree lame or anything. :) It's just that he
apparently has rather experimental stuff in it, which can always lead to
instabilities.


--
Earthling Michel Dänzer (MrCooper)    \   Debian GNU/Linux (powerpc) developer
CS student, Free Software enthusiast   \        XFree86 and DRI project member

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: xine, ppc and illegal instructions

[Bill Fink]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 1091 bytes --]


> On Sun, 1 Apr 2001, Michel [iso-8859-1] Dänzer wrote:
>
> Bill Fink wrote:
>
> > I updated to the latest Paulus rsync kernel (2.4.3-pre8) and the
> > latest gcc (2.95.3-2v) and 2.1 glibc (glibc-2.1.3-15g) from Franz,
> > but unfortunately none of this helps.  xine 0.4.01 still gets
> > illegal instructions (sometimes it gets a segmentation fault
> > instead).
>
> Have you tried other kernels? A lot of people including me have experienced
> sporadic signals, most often with ldconfig, with Paulus' tree. I'm running
> BenH's tree now and haven't seen it yet.
>
> This is not to call Paulus' tree lame or anything. :) It's just that he
> apparently has rather experimental stuff in it, which can always lead to
> instabilities.

Hey, Grrrrrrrrrrrrrreattt!!!!!

That did the trick.  I rsync'ed BenH's latest 2.4.3 final kernel,
and now xine 0.4.01 works fine.  Now I just have to get MOL working
again with the latest kernels (probably just requires a rebuild).

Many, many thanks for the suggestion!

						-Bill


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: xine, ppc and illegal instructions

[Kevin B. Hendricks]

Hi,

couple of  things:

- was the shared library loaded by dlopen properly built with -fPIC or -fpic?

- could there be a cache flushing bug?  When run in gdb if you set some
breakpoints in the shared library, it will flush the icache (to make sure the
breakpoint gets flushed out of data cache and any preloaded instruction are
thrown away) this in turn seems to "fix" the cache flush problem if one
exists.

- can you set ulimit -c unlimited and generate a core file from xine
  and post the resulting backtrace.

  If it looks empty, try the following:
  x/20i $lr -32
  in gdb just in case the problem was a branch out into the weeds

(if we are lucky lr will have the return address so that we can
possibly see at least where the bad branch comes from).  One way to get
an illegal instruction is to follow a calculated branch into the weeds
(happens sometimes in some C++ code during tailcalls when compiled above -O0).

Kevin

On Sunday 01 April 2001 13:51, Bill Fink wrote:
> Some further investigation on my part and a question for Franz Sirl:
>
> I updated to the latest Paulus rsync kernel (2.4.3-pre8) and the
> latest gcc (2.95.3-2v) and 2.1 glibc (glibc-2.1.3-15g) from Franz,
> but unfortunately none of this helps.  xine 0.4.01 still gets
> illegal instructions (sometimes it gets a segmentation fault
> instead).  No core dump is produced and it runs basically OK
> when run under control of gdb, so it makes tracking down the
> problem very difficult.
>
> From debug printout, it appears that it is dying in a call to dlopen,
> which is in libdl, which is part of glibc.  Here's the tail end of an
> strace of a xine run:
>
> open("/usr/local/install/xine-0.4.01/lib/xine/plugins",
O_RDONLY|O_NONBLOCK|O_DI
> RECTORY) = 7
> fstat(7, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> fcntl(7, F_SETFD, FD_CLOEXEC)           = 0
> lseek(7, 0, SEEK_CUR)                   = 0
> getdents(7, /* 12 entries */, 2980)     = 284
> open("/usr/local/install/xine-0.4.01/lib/xine/plugins/input_file.so",
O_RDONLY)
> = 8
> fstat(8, {st_mode=S_IFREG|0755, st_size=17054, ...}) = 0
> read(8, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\0\t"..., 4096)
= 409
> 6
> mmap(0xfa28000, 70000, PROT_READ|PROT_EXEC, MAP_PRIVATE, 8, 0) = 0xfa28000
> mprotect(0xfa29000, 65904, PROT_NONE)   = 0
> mmap(0xfa38000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED, 8,
> 0) = 0xfa38000
> close(8)                                = 0
> mprotect(0xfa28000, 4096, PROT_READ|PROT_WRITE) = 0
> mprotect(0xfa28000, 4096, PROT_READ|PROT_EXEC) = 0
> --- SIGILL (Illegal instruction) ---
> +++ killed by SIGILL +++
>
> Given that the last system call was an mprotect, I searched the archives
> and discovered that Olaf Hering reported a problem with mprotect on
> January 23 on the linuxppc-dev list, see:
>
> http://lists.linuxppc.org/listarcs/linuxppc-dev/200101/msg00324.html
>
> Olaf provided a patch to fix the problem, which I wasn't totally clear
> exactly what it was against, but I'm assuming it was glibc (I've never
> looked at the glibc source).  Assuming it was a glibc patch, it wouldn't
> be in the glibc-2.1.3-15g I downloaded since that was dated January 14.
>
> Now my question for Franz.  Do you think the problem/patch reported
> by Olaf is likely related to the apparent dlopen/mprotect problem I'm
> having with the 0.4.01 version of xine (note the 0.3.7 version works
> fine)?  Or could it possibly be hardware related?  I'm running on a
> G4 which has Altivec, while Henry's system is a G3 IIRC, which I believe
> doesn't have Altivec (or some other hardware difference).
>
> I've pulled down the source for glibc-2.1.3-15g, but before I actually
> try rebuilding it on my system (with or without Olaf's patch), I'd
> appreciate some expert advice about whether it's worth the effort or
> likely to have any effect.
>
> 						-Thanks
>
> 						-Bill
>
>
>

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: xine, ppc and illegal instructions

[Benjamin Herrenschmidt]

>- could there be a cache flushing bug?  When run in gdb if you set some
>breakpoints in the shared library, it will flush the icache (to make sure the
>breakpoint gets flushed out of data cache and any preloaded instruction are
>thrown away) this in turn seems to "fix" the cache flush problem if one
>exists.

Franz and I checked glibc for the cache flushing problem reported by
Samuel Rydth and it's ok. However, the kernel did miss those sync's.
I can't tell if it's the cause of the problem, however, my rsync kernel
have those changes. I'll push them to bk soon.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: xine, ppc and illegal instructions

[Bill Fink]

> On Sun, 1 Apr 2001, Kevin B. Hendricks wrote:
>
> Hi,
>
> couple of  things:
>
> - was the shared library loaded by dlopen properly built with -fPIC or -fpic?

I assume so.  It's Franz Sirl's latest 2.1 glibc RPM.

> - could there be a cache flushing bug?  When run in gdb if you set some
> breakpoints in the shared library, it will flush the icache (to make sure the
> breakpoint gets flushed out of data cache and any preloaded instruction are
> thrown away) this in turn seems to "fix" the cache flush problem if one
> exists.

That makes sense to me.

> - can you set ulimit -c unlimited and generate a core file from xine
>   and post the resulting backtrace.
>
>   If it looks empty, try the following:
>   x/20i $lr -32
>   in gdb just in case the problem was a branch out into the weeds

I was never able to get a core dump.  My coredumpsize is unlimited.
Earlier in the xine code, I could force a core dump by doing a "*0 = 1"
before the first call to pthread_create, but I couldn't get a core dump
by doing the same thing right after that call.

> (if we are lucky lr will have the return address so that we can
> possibly see at least where the bad branch comes from).  One way to get
> an illegal instruction is to follow a calculated branch into the weeds
> (happens sometimes in some C++ code during tailcalls when compiled above -O0).

As reported in my previous message, it's now working using the latest
BenH kernel (2.4.3 final) instead of the Paulus kernel (2.4.3-pre8) I
was previously trying with, so I'm happy.

						-Thanks

						-Bill


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: xine, ppc and illegal instructions

[Kevin B. Hendricks]

Hi,

> > - could there be a cache flushing bug?  When run in gdb if you set some
> > breakpoints in the shared library, it will flush the icache (to make sure
the
> > breakpoint gets flushed out of data cache and any preloaded instruction
are
> > thrown away) this in turn seems to "fix" the cache flush problem if one
> > exists.
>
> That makes sense to me.


> As reported in my previous message, it's now working using the latest
> BenH kernel (2.4.3 final) instead of the Paulus kernel (2.4.3-pre8) I
> was previously trying with, so I'm happy.

Isn't Ben's rsync kernel the one with a change in the kernel cache flushing
code?

Samuel's message said the sequence should be

         stw     r4,0(r2)                        // store instruction
         dcbst   0,r2                            // Flush cache
         sync
         icbi    0,r2
         sync
         isync

I have sometimes seen code where you can batch things up with multiple  dcbf
and icbi before the final sync isync.

So does the batch version work properly on a 7400 series or not?

Either way, we should probably check the cache flushing code in XFree86  (it
has its own dynamic loader) and OpenOffice (bridges code uses self-modifying
code) and  the ppc closures code in libffi used by gcj to flush trampolines
and whatever ever other userland code uses cache flushing because many may
have been based on the kernel version of that routine.

I will check the latter two (OpenOffice and the gcj trampoline flush) since I
have easy access to that code.  Has anyone checked the XFree86 cache flushing
code?

Any info on if the flush a cache range with batched dcbf and icbi's version
used by the kernel works properly under 7400 would be greatly appreciated.

Kevin


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: xine, ppc and illegal instructions

[Henry Worth]

Bill Fink wrote:
>
>A theory why xine 0.4.01 would work on Henry's system but not on mine
>was that Henry was running with a newer glibc (2.2.something).  I was

Actually, I'm at 2.1.3 and 2.95.3 compiler, but the common
denominator for those failing seems to be Debian distributions,
whereas I'm LPPC Q4.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: xine, ppc and illegal instructions

[Bill Fink]

> On Thu, 29 Mar 2001, Henry Worth wrote:
>
> Bill Fink wrote:
> >
> >A theory why xine 0.4.01 would work on Henry's system but not on mine
> >was that Henry was running with a newer glibc (2.2.something).  I was
>
> Actually, I'm at 2.1.3 and 2.95.3 compiler, but the common
> denominator for those failing seems to be Debian distributions,
> whereas I'm LPPC Q4.

OK, maybe it's the compiler.  I'm running YDL 1.2.1 with:

gwiz% rpm -q -a | egrep 'gcc|glibc'
gcc-2.95.2-1i
gcc-c++-2.95.2-1i
gcc-objc-2.95.2-1i
gcc-g77-2.95.2-1i
glibc-2.1.3-15f
glibc-devel-2.1.3-15f

You're running gcc-2.95.3 while I'm running gcc-2.95.2-1i.

Well so much for that theory.  I just upgraded to gcc-2.95.3-2n from
LPPC 2000 Q4 and it didn't help.

How about shared libraries?  Here's the list of packages from my
system that provide shared libraries for xine (from ldd):

	glibc-2.1.3-15f
	XFree86-libs-4.0.2-2a
	imlib-1.9.8-1
	libjpeg-devel-6b-10
	libtiff-devel-3.5.4-5
	libungif-4.1.0-3
	libpng-devel-1.0.5-3
	zlib-1.1.3-6
	esound-0.2.20-0
	audiofile-0.1.9-3

Henry, could you please let me know what versions of the above you
are running on your system so I can compare?

I have a suspicion it might be an X problem although I can't say why
I feel that way.  I'm running using Xv on an ATY Rage128.

						-Thanks

						-Bill


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: xine, ppc and illegal instructions

[Henry Worth]

Franz Sirl wrote:
>>At 07:30 27.03.2001, Bill Fink wrote:
>>         *  In configure, there's a case check for"powerpc-*-linux*)".
>>            This should be changed to "powerpc-*-linux* | ppc-*-linux*)".

>This isn't correct, it's always powerpc-*-linux*, the other one is
>superflous. This usually happens if people didn't update their configure
>scripts for a _long_ time and your patch is just papering over that.
>
>Franz.


No, LinuxPPC 2000 Q4 is ppc-*, what version of the
config scripts, I don't know, and don't care. A
lot of packages break because of it, allow both
and save a lot of grief!

Henry

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: xine, ppc and illegal instructions

[David Edelsohn]

	The configuration target is powerpc-*-linux, not ppc-*-linux.
At best ppc-* could be converted to powerpc-*.  It's too bad that people
made the wrong assumption about the configuration name, but there is not
reason to encourage that.

David


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: xine, ppc and illegal instructions

[Henry Worth]

David Edelsohn wrote:
>
>         The configuration target is powerpc-*-linux, not ppc-*-linux.
> At best ppc-* could be converted to powerpc-*.  It's too bad that people
> made the wrong assumption about the configuration name, but there is not
> reason to encourage that.
>
> David

And what gods defined and documented it??? A lot of
packages are broke this way. My system has current
config scripts, config.guess/sub return powerpc-*.
The xine configure even uses them and has
a $host that is powerpc-* and without
ppc-* in the case will display an unsupported
message using $host which displays powerpc-*.
But, for some reason they use the un-canonized
$host_alias for the case statement which is ppc-*.

The bottom line is configure is a pile of
overly convoluted, underdocumented &*##. Most
package maintainers just copy from some other
already broken package and hack-n-slash till
it works on their x86 platform and leave it at
that. Getting pedantic about powerpc-* gets us
nowhere.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: xine, ppc and illegal instructions

[Bill Fink]

Yup, I got the same illegal instructions in xine 0.4.01, and it would
sorta work running under gdb.  It seems to be dying in dlopen, which
is part of /lib/libdl.so.2.  On my system:

gwiz% rpm -q -f /lib/libdl.so.2
glibc-2.1.3-15f

A theory why xine 0.4.01 would work on Henry's system but not on mine
was that Henry was running with a newer glibc (2.2.something).  I was
going to try upgrading my glibc, but that turned out it was going to
require updating in excess of 60 RPMs to satisfy all the dependencies,
so I've temporarily shelved that idea.  YDL 2.0 is supposed to be
released RSN, which includes a 2.2 glibc, so I'll be upgrading to
that once it's available to see if it makes a difference (I may even
try using the 2.0 beta RPMs in advance of the official release).

If you want to try the stable 0.3.7 version of xine, I have a patch
to build it for PPC, and the 0.3.7 version doesn't encounter the
illegal instruction problem.  See my message from March 8 on the
xine-user e-mail archive for the patch (start at http://xine.sourceforge.net/).

There are two minor changes to that patch.

	*  In audio_out/audio_oss_out.c, the patch changed the constant
	   90000 to 88200.  It has since been pointed out to me that
	   this was incorrect and the constant should be left as 90000.

	*  In configure, there's a case check for "powerpc-*-linux*)".
	   This should be changed to "powerpc-*-linux* | ppc-*-linux*)".

Of course I really want to get to use 0.4.01 for its new functionality
such as audio/video synchronization and reported performance improvements,
but I'm stuck for the moment until I can upgrade to YDL 2.0.

						-Bill



> On Sat, 24 Mar 2001, Henry Worth wrote:
>
> > Stefan Berndtsson <stefan@nocrew.org> wrote:
>
> > I'll wait for the new patches and see if that changes >anything though.
>
> Nothing in the patches for this problem, which is
> quite recreatable, Bill Fink was looking into
> this. If the esd daemon is running (just disabling desktop sounds is not enough, kill the
> daemon) and
> you run without -A esd, you will get ill. instr.
> on ppc, unless running in gdb. ESD is useless
> for this anyway, no hope of syncing A/V, at
> least till they fix the esd_get_latency() call
> which just hangs on both PPC and x86.
>
> BTW - the xine user maillists would be a better
> forum for this - <http://xine.sourceforge.net/>
> I'm mailing you the cummalative patch.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: xine, ppc and illegal instructions

[Henry Worth]

Stefan Berndtsson <stefan@nocrew.org> wrote:

Henry Worth <haworth@ncal.verio.com> writes:

> Shutdown esd (best) or use the -A esd option.

>I'm afraid that doesn't help at all. It still produces >the illegal instruction.
>Hmm.. running it using strace, I can sometimes make it >get past the plugin-
>check and show the box. This nearly never happens with >all the plugins
>available, but gets easier if I remove some of them.

>I'll wait for the new patches and see if that changes >anything though.

Nothing in the patches for this problem, which is
quite recreatable, Bill Fink was looking into
this. If the esd daemon is running (just disabling desktop sounds is not enough, kill the
daemon) and
you run without -A esd, you will get ill. instr.
on ppc, unless running in gdb. ESD is useless
for this anyway, no hope of syncing A/V, at
least till they fix the esd_get_latency() call
which just hangs on both PPC and x86.

BTW - the xine user maillists would be a better
forum for this - <http://xine.sourceforge.net/>
I'm mailing you the cummalative patch.

Henry

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: xine, ppc and illegal instructions

[Henry Worth]

BTW, a change in 0.4.01 that doesn't seem
to be documented anywere. To play DVD's and
VCD's, you will need to create links to the
dvd and/or cdrom /dev/* devices for
/dev/dvd and /dev/vcd.

Also, if you don't have a disk loaded, don't
hit the dvd or vcd playlist scan buttons and
if the playlist has a DVD/VCD "MRL" -- don't
select play, <<, >>, or anything else that
might result in an I/O. And to eject, select
stop and give the drive a chance to spin-down
before selecting eject. There is virtually no
status or error checking for the IOCTLS and
other I/O functions. This results in requests
for functions that are not valid for the drive's current state and result in long
bus-reset/retry recovery sequences, often with focus grabbed,
giving the appearance of a hung machine (part
of this may be driver problems).

I've uploaded some more patches to
ftp.linuxppc.org's incoming, they fix a nasty
rogue threads problem and some more queuing
problems that are responsible for a lot of the
hangs during playback. Hopefully, they will
get moved to contrib/unpackaged in a few days.

Henry

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: xine, ppc and illegal instructions

[Henry Worth]

Shutdown esd (best) or use the -A esd option.

Henry

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: xine, ppc and illegal instructions

[Stefan Berndtsson]

Henry Worth <haworth@ncal.verio.com> writes:

> Shutdown esd (best) or use the -A esd option.

I'm afraid that doesn't help at all. It still produces the illegal instruction.
Hmm.. running it using strace, I can sometimes make it get past the plugin-
check and show the box. This nearly never happens with all the plugins
available, but gets easier if I remove some of them.

I'll wait for the new patches and see if that changes anything though.

/Stefan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

xine, ppc and illegal instructions

[Stefan Berndtsson]

I tried compiling xine-0.4.01 with the ppc-patches by Henry Worth.
Compiling went fine.

When running the resulting binary, I end up with an Illegal instruction.
It doesn't seem to matter what mpegfile I try to use it on, so I assume
it dies before messing with the mpeg.

An strace of the program gives this at the end:

open("/usr/local/lib/xine/plugins/input_net.so", O_RDONLY) = 9
read(9, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\0\v"..., 1024) = 1024
SYS_197(0x9, 0x7fffec40, 0x7fffec40, 0x101f3170, 0) = 0
mmap(0xf993000, 71456, PROT_READ|PROT_EXEC, MAP_PRIVATE, 9, 0) = 0xf993000
mprotect(0xf995000, 63264, PROT_NONE)   = 0
mmap(0xf9a3000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 9,
0) = 0xf9a3000
close(9)                                = 0
mprotect(0xf993000, 8192, PROT_READ|PROT_WRITE) = 0
mprotect(0xf993000, 8192, PROT_READ|PROT_EXEC) = 0
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++


Kernel version is 2.4.0, with some dmasound-patches applied.
Distribution is Debian (reasonably fresh).
Glibc 2.2.2-1

The binary has been compiled both with and without optimisations, with no
appearent difference.

The above could hint that input_net.so was a problem, so I removed that one,
and then just the next input showed up with a more or less identical trace.
Is this a libc problem? Is it something else? I have no idea where to look.
Since I can't even get a coredump to look in, I guess this isn't really in
the binary.

/Stefan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: xine, ppc and illegal instructions

[Gregorio Gervasio Jr.]

>>>>> On Sat, 24 Mar 2001 00:53:54 +0100, Stefan Berndtsson <stefan@nocrew.org> said:

s> I tried compiling xine-0.4.01 with the ppc-patches by Henry Worth.
s> Compiling went fine.

s> When running the resulting binary, I end up with an Illegal instruction.
s> It doesn't seem to matter what mpegfile I try to use it on, so I assume
s> it dies before messing with the mpeg.

        I was just starting to play with this last night.  When I
tried to run under gdb, I didn't get the errors.  (I haven't tried any
streams yet -- my machine locked up trying to read the DVD.)

Gregorio Gervasio, Jr.
gtgj@pacbell.net

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/