| Summary: | media-tv/kodi-9999 with media-libs/giflib-5.1.4-r1 - segmentation fault in TexturePacker in DGifDecompressLine () from /usr/lib64/libgif.so.7 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Steffen Hau <steffen> |
| Component: | Current packages | Assignee: | Sebastian Pipping <sping> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | sping, vapier |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=637636 https://bugs.gentoo.org/show_bug.cgi?id=677956 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
kodi-999-build.log.xz
Patch a) rename local reallocarray, rename export Patch b) drop local reallocarray, rely on glibc Patch c) drop export, rename implementation, add internal prototype Better patch |
||
|
Description
Steffen Hau
2018-03-28 14:48:04 UTC
same here, including the giflib version dependency thing. According to coredumpctl gdb, it's trying to write "Line" into some unallocated place in memory. Pretty strongly suggests that there is some kind of problem with the -r1 patch in giflib, or else with gcc. I tried -O1 and disabling sandbox with the same result so... it's probably something to do with the patch, or with some kind of inter-library alloc/free asymmetry, or similar bug to the giflib bug that also needs patching in kodi. too busy to screw around with it atm, maybe this weekend if I can find some time. perhaps a job for valgrind. sping, can you help us out here? This appears to be a regression caused by https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=010e1c17d6268e0747b362d3ba81f1e17d9b9f9d Created attachment 526172 [details, diff]
Patch a) rename local reallocarray, rename export
I'll need your help with testing. There's two ways that could work:
a) rename local reallocarray, keep using it, keep the export but with a
new name
b) drop local reallocarray and the export, rely on reallocarray from glibc
I'll attach patches for both to try in place of the current giflib-5.1.4-reallocarray-export.patch applied by 5.1.4-r1.
So here's the patch for (a), will be followed by (b) in a second.
Created attachment 526174 [details, diff]
Patch b) drop local reallocarray, rely on glibc
Hi Sebastian, I applied your patches separately to giflib-5.1.4 and can confirm that TexturePacker doesn't segfault with any of the two patches. Any Idea why the original patch causes the segfault? Created attachment 526178 [details, diff] Patch c) drop export, rename implementation, add internal prototype (In reply to Steffen Hau from comment #5) > I applied your patches separately to giflib-5.1.4 and can confirm that > TexturePacker doesn't segfault with any of the two patches. Cool, thank you! > Any Idea why the > original patch causes the segfault? My guess is the lack of a prototype for function openbsd_reallocarray. There are warnings for it and it seems that without the prototype, the return type is assumed int which takes fewer bytes than a pointer in 64 bit architectures: dgif_lib.c:399:27: warning: implicit declaration of function 'openbsd_reallocarray' [-Wimplicit-function-declaration] (SavedImage *)openbsd_reallocarray(GifFile->SavedImages, ^ dgif_lib.c:399:13: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] (SavedImage *)openbsd_reallocarray(GifFile->SavedImages, ^ I have made a patch (c) to verify that assumption if you're curious as well. I still wonder what patch to go with, best. I worry that (b) may not work well with some non-glibc libc implementations. I'm unsure if symbols in .so files are also addressed by number or just by name. If there's a chance for by number, then (a) may be the safest? Help! :) vapier, any ideas? I'll go with a) for a start in a minute. We can still switch to b) or c). The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=563462332a85910db21a6308523177ff9c80afc8 commit 563462332a85910db21a6308523177ff9c80afc8 Author: Sebastian Pipping <sping@gentoo.org> AuthorDate: 2018-03-31 15:33:26 +0000 Commit: Sebastian Pipping <sping@gentoo.org> CommitDate: 2018-03-31 15:35:01 +0000 media-libs/giflib: Fix 5.1.4-r1 segfaults Bug: https://bugs.gentoo.org/651820 Package-Manager: Portage-2.3.26, Repoman-2.3.7 .../files/giflib-5.1.4-reallocarray-export.patch | 23 +++++++++++----------- ...flib-5.1.4-r1.ebuild => giflib-5.1.4-r2.ebuild} | 0 2 files changed, 11 insertions(+), 12 deletions(-)} (In reply to Sebastian Pipping from comment #6) > I still wonder what patch to go with, best. I worry that (b) may not work > well with some non-glibc libc implementations. reallocarray() was introduced in glibc 2.26: https://sourceware.org/ml/libc-alpha/2017-08/msg00010.html Created attachment 526226 [details, diff]
Better patch
This better patch results in:
- configure checks if reallocarray() function is available in C standard library.
- If reallocarray() is available, libgif.so.7.0.0 uses it.
- If reallocarray() is not available, the implementation from openbsd-reallocarray.c is used and the symbol in libgif.so.7.0.0 is named "openbsd_reallocarray".
With this approach, if giflib is firstly built with glibc <2.26 without reallocarray() and next glibc is updated to a version >=2.26 with reallocarray() but giflib is not rebuilt, there will be no symbol collisions.
Looks pretty good to me. Since that is more of an upstreamable patch now, please take it upstream for review at https://sourceforge.net/p/giflib/bugs/110/ . Thanks! Assigning to sping since the issues with media-libs/giflib, not kodi. Thanks! To my understanding the issue is fixed in Gentoo. Closing. (In reply to Arfrever Frehtes Taifersar Arahesis from comment #11) > Created attachment 526226 [details, diff] [details, diff] > Better patch > > This better patch results in: > - configure checks if reallocarray() function is available in C standard > library. > - If reallocarray() is available, libgif.so.7.0.0 uses it. > - If reallocarray() is not available, the implementation from > openbsd-reallocarray.c is used and the symbol in libgif.so.7.0.0 is named > "openbsd_reallocarray". https://sourceforge.net/p/giflib/code/ci/95785572710fa6cdb6755b65293dea69f4ad1f61/ |
