Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 87898 (realplayer) - Real Player 8 will not run with NPTL
Summary: Real Player 8 will not run with NPTL
Keywords:
Status: CLOSED NOTABUG
Alias: realplayer
Product: Red Hat Linux
Classification: Retired
Component: glibc
Version: 9
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
: 86440 89108 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-04-03 16:43 UTC by Callum Benepe
Modified: 2016-11-24 15:23 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2003-04-19 09:19:05 UTC
Embargoed:


Attachments (Terms of Use)

Description Callum Benepe 2003-04-03 16:43:11 UTC
Description of problem: Real Player 8 will not run on Red Hat 9 stock kernel,
but if I compile a custom kernel it works.
I don't know what I enable to make it work, but it does.


Version-Release number of selected component (if applicable):


How reproducible: Just install Real Player 8, and try to start it.


Steps to Reproduce:
1.
2.
3.
    
Actual results: Won't start


Expected results: Play audio


Additional info:

Comment 1 Michael Schwendt 2003-04-04 15:40:56 UTC
Duplicate of bug #86440.

Comment 2 Michael Schwendt 2003-04-04 15:54:31 UTC
Since I get a fatal error upon trying to add a comment to  bug #86440 (I have
submitted a bug report about this as bug #88008), I add my comment here:

Realplayer works for me with either of

env LD_ASSUME_KERNEL=2.2.5 realplay
env LD_ASSUME_KERNEL=2.4.1 realplay

Though, the Realplayer plug-in for Mozilla is likely to cause trouble.


Comment 3 Mike A. Harris 2003-04-19 09:00:13 UTC
*** Bug 86440 has been marked as a duplicate of this bug. ***

Comment 4 Mike A. Harris 2003-04-19 09:01:03 UTC
*** Bug 89108 has been marked as a duplicate of this bug. ***

Comment 5 Mike A. Harris 2003-04-19 09:19:05 UTC
While there is a bug occuring here, it is a bug in real player, not in glibc,
not in XFree86, not in the kernel.

It is understandable that when people experience problems in software that
didn't occur in past releases that they will assume that it is some new
regression in some software component in new operating system releases.

The real problem, is that various applications are written with certain
broken assumptions in them, such as relying on library routines to exist
which aren't standard, or relying on certain routines to work a certain
way when the way they are expecting things to work is officially
"undefined".

Any application is by definition "broken", if it is written to expect a
certain specific defined behaviour from any library or interface, which is
officially "undefined".  When something is undefined it means that any
behaviour may occur and that you can't rely on any specific behavior, or
if you could, then it would by definition be "defined standard behavior"
and wouldn't be undefined to begin with.

Why then does something work in one release, and not in another?  Simple,
"undefined behaviour", may result in something working just fine with a piece
of code, even though that code is broken, the undefined behaviour just so
happens to provide behaviour at that time that the broken application expects,
and so "it just works".  Later, in future releases, when that behaviour
changes but still remains undefined, the applications which relied on a
*specific* behaviour out of an undefined interface end up no longer working,
and what you end up with, is things like realplayer no longer working due
to relying on undefined behaviour which has changed.

The real bug in these cases is in the applications themselves, and the real
fix, is for the supplier of the broken applications to fix them and release
updates.  Hopefully in doing so, they remove all reliance on undefined
behaviour so that their applications don't break again in the future as
other undefined things change.  Once users upgrade to the fixed application,
they no longer will experience the problem from the broken application
version which just randomly happened to work previously.

Red Hat additionally provides some levels of backward compatibility which
may or may not allow broken applications to work, by providing both the
new interfaces, as well as some of the older ones.  By default, the new
system is used, and when users experience broken applications such as
realplayer, some Java implementations, Adobe acroread, and some other
similarly broken software, users can use LD_ASSUME_KERNEL as Michael Schwendt
mentions above to work around the bugs in the broken software.

There are some comments about this in the RELEASE-NOTES of the distribution
as well.

Hopefully the various broken applications out there will get fixed soon to
not rely on broken undefined behaviour, and users will be able to upgrade
the software they use to newer bug fixed versions.  In the meantime, use
the workarounds which Red Hat graciously provides to users to use the
various broken software out there, while at the same time progressing forward
with technology enhancements that continue to make Linux a strong technology,
without having to crud up the kernel, glibc and other interfaces with long
term compatibility hacks and kludges to make up for the flaws in various
broken software out in the wild.





Note You need to log in before you can comment on or make changes to this bug.