After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 335013 - Check for busted posix_memalign
Check for busted posix_memalign
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-libav
0.10.0
Other Linux
: Normal major
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 419555 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-03-18 16:38 UTC by Jens Granseuer
Modified: 2008-04-21 12:20 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
check for valid posix_memalign implementation (1.53 KB, patch)
2006-03-18 16:39 UTC, Jens Granseuer
reviewed Details | Review

Description Jens Granseuer 2006-03-18 16:38:57 UTC
The glibc on my system (2.2.2) has a broken posix_memalign implementation that cannot allocate arbitrary block sizes. As a result, av_malloc returns NULL, and plugins relying on this orking (e.g. ffmpegdec) crash due to NULL pointer dereferencing.

The following patch makes configure check whether posix_memalign actually works correctly, and also introduces memalign as a possible replacement.
Comment 1 Jens Granseuer 2006-03-18 16:39:47 UTC
Created attachment 61503 [details] [review]
check for valid posix_memalign implementation
Comment 2 Tim-Philipp Müller 2006-05-18 10:09:52 UTC
Just to ask the obvious:

 - have you tried pushing this patch upstream already?

 - do we _really_ need to work around such a basic function being broken
   (rather than just say 'don't use glibc-2.2.2 then')? (sigh)


Comment 3 Jens Granseuer 2006-05-18 10:26:22 UTC
By upstream you mean ffmpeg, I assume? I did check the ffmpeg repository, but they seem to use a different build system and additionally use memalign instead of posix_memalign anyway, so they don't need the patch.

I don't know how to answer the second question, except to say that I'd consider it a pain to have to upgrade glibc (and the switch to 2.3 would include switching compilers to gcc 3, which in turn breaks C++ ABI, which...). FWIW, glib has added a similar check to configure to protect against this broekn version, and does this small check really hurt that much?
Comment 4 Jens Granseuer 2006-06-23 14:28:22 UTC
As an additional data point, this is an issue with all glibc < 2.3.
Here's the relevant part from the 2.2.5 -> 2.3 patch.

 int
 __posix_memalign (void **memptr, size_t alignment, size_t size)
@@ -4901,16 +5337,15 @@ __posix_memalign (void **memptr, size_t 
 
   /* Test whether the SIZE argument is valid.  It must be a power of
      two multiple of sizeof (void *).  */
-  if (size % sizeof (void *) != 0 || (size & (size - 1)) != 0)
+  if (alignment % sizeof (void *) != 0 || !powerof2 (alignment) != 0)
     return EINVAL;
Comment 5 Edward Hervey 2006-10-07 07:06:12 UTC
Jens, the latest ffmpeg snapshot includes modifications relevent to memalign. Could you give a try with the latest cvs of gst-ffmpeg (without your patch applied) and tell us if it works ?
Comment 6 Jens Granseuer 2006-10-09 11:28:22 UTC
So, for the record: No, the problematic piece of code comes from gst-ffmpeg itself replacing the use of memalign (used upstream) with posix_memalign, which is broken with glibc < 2.3 und usually returns NULL -> segfault.

Even if this gst modification is not reverted (as requested in bug 172961), I think the above patch is completely safe since it only falls back to memalign if posix_memalign is found to be non-functional. It can't get worse than segfaulting in any case.
Comment 7 David Schleef 2006-10-11 05:48:19 UTC
The glibc-2.2 series has a long list of security holes.  I can't imagine people still using it for serious work unless they're using Debian/woody or RHEL3 (?), both of which have the posix_memalign bugfix.

posix_memalign is standard; memalign isn't.
Comment 8 David Schleef 2007-03-18 01:05:52 UTC
*** Bug 419555 has been marked as a duplicate of this bug. ***
Comment 9 Edward Hervey 2008-04-21 12:20:15 UTC
no longer valid since we no longer patch ffmpeg. If issue is still active, bug the ffmpeg maintainers.