Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 716198 - net-im/discord-bin-0.0.10 segfaults
Summary: net-im/discord-bin-0.0.10 segfaults
Status: RESOLVED UPSTREAM
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Randall
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-04-04 16:37 UTC by marius.spix
Modified: 2022-05-26 15:13 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
strace output (strace.txt,63.51 KB, text/plain)
2020-04-13 13:19 UTC, marius.spix
Details
Valgrind output (valgrind.txt,3.85 KB, text/plain)
2020-10-07 21:53 UTC, marius.spix
Details

Note You need to log in before you can comment on or make changes to this bug.
Description marius.spix 2020-04-04 16:37:34 UTC
After updating to 0.0.10, net-im/discord-bin segfaults.


dmesg output

[  957.636684] discord[5856]: segfault at 562700035d98 ip 00007fe6c8afbeb4 sp 00007ffcf9dfb800 error 6 in ld-2.29.so[7fe6c8af0000+26000]
[  957.636690] Code: 1f 80 00 00 00 00 48 8b 08 8b 50 08 4c 01 d1 48 83 fa 26 74 0a 48 83 fa 08 0f 85 e5 0f 00 00 48 8b 50 10 48 83 c0 18 4c 01 d2 <48> 89 11 48 39 c3 77 d4 e9 a1 fa ff ff 0f 1f 80 00 00 00 00 4c 89


ldd /usr/bin/discord
	linux-vdso.so.1 (0x00007ffd92ff1000)
	libffmpeg.so => not found
	libdl.so.2 => /lib64/libdl.so.2 (0x00007fc9cb010000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc9cadef000)
	librt.so.1 => /lib64/librt.so.1 (0x00007fc9cabe7000)
	libgobject-2.0.so.0 => /usr/lib64/libgobject-2.0.so.0 (0x00007fc9d226f000)
	libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x00007fc9d2133000)
	libgio-2.0.so.0 => /usr/lib64/libgio-2.0.so.0 (0x00007fc9caa1d000)
	libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007fc9ca8b7000)
	libX11-xcb.so.1 => /usr/lib64/libX11-xcb.so.1 (0x00007fc9d212e000)
	libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007fc9ca88a000)
	libXcomposite.so.1 => /usr/lib64/libXcomposite.so.1 (0x00007fc9d212a000)
	libXcursor.so.1 => /usr/lib64/libXcursor.so.1 (0x00007fc9d211c000)
	libXdamage.so.1 => /usr/lib64/libXdamage.so.1 (0x00007fc9d2116000)
	libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007fc9ca872000)
	libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00007fc9d210f000)
	libXi.so.6 => /usr/lib64/libXi.so.6 (0x00007fc9ca85e000)
	libXrender.so.1 => /usr/lib64/libXrender.so.1 (0x00007fc9ca851000)
	libXtst.so.6 => /usr/lib64/libXtst.so.6 (0x00007fc9d2106000)
	libnss3.so => /usr/lib64/libnss3.so (0x00007fc9ca71e000)
	libnssutil3.so => /usr/lib64/libnssutil3.so (0x00007fc9ca6ec000)
	libsmime3.so => /usr/lib64/libsmime3.so (0x00007fc9ca6c3000)
	libnspr4.so => /usr/lib64/libnspr4.so (0x00007fc9ca681000)
	libgdk_pixbuf-2.0.so.0 => /usr/lib64/libgdk_pixbuf-2.0.so.0 (0x00007fc9ca655000)
	libgtk-3.so.0 => /usr/lib64/libgtk-3.so.0 (0x00007fc9c9ec9000)
	libgdk-3.so.0 => /usr/lib64/libgdk-3.so.0 (0x00007fc9c9dff000)
	libpangocairo-1.0.so.0 => /usr/lib64/libpangocairo-1.0.so.0 (0x00007fc9c9df0000)
	libpango-1.0.so.0 => /usr/lib64/libpango-1.0.so.0 (0x00007fc9c9da0000)
	libatk-1.0.so.0 => /usr/lib64/libatk-1.0.so.0 (0x00007fc9c9d79000)
	libcairo.so.2 => /usr/lib64/libcairo.so.2 (0x00007fc9c9bf7000)
	libdbus-1.so.3 => /usr/lib64/libdbus-1.so.3 (0x00007fc9c9ba3000)
	libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007fc9c9b67000)
	libuuid.so.1 => /lib64/libuuid.so.1 (0x00007fc9c9b5e000)
	libXrandr.so.2 => /usr/lib64/libXrandr.so.2 (0x00007fc9c9b51000)
	libXss.so.1 => /usr/lib64/libXss.so.1 (0x00007fc9c9b4c000)
	libasound.so.2 => /usr/lib64/libasound.so.2 (0x00007fc9c9a50000)
	libatk-bridge-2.0.so.0 => /usr/lib64/libatk-bridge-2.0.so.0 (0x00007fc9c9a1c000)
	libm.so.6 => /lib64/libm.so.6 (0x00007fc9c96d2000)
	libatspi.so.0 => /usr/lib64/libatspi.so.0 (0x00007fc9c9699000)
	libcups.so.2 => /usr/lib64/libcups.so.2 (0x00007fc9c9606000)
	libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/libgcc_s.so.1 (0x00007fc9c95ec000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fc9c9221000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fc9d20df000)
	libffi.so.6 => /usr/lib64/libffi.so.6 (0x00007fc9c9216000)
	libpcre.so.1 => /lib64/libpcre.so.1 (0x00007fc9c9194000)
	libgmodule-2.0.so.0 => /usr/lib64/libgmodule-2.0.so.0 (0x00007fc9c918f000)
	libz.so.1 => /lib64/libz.so.1 (0x00007fc9c916d000)
	libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fc9c8f56000)
	libmount.so.1 => /lib64/libmount.so.1 (0x00007fc9c8ef0000)
	libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007fc9c8eeb000)
	libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00007fc9c8ee1000)
	libplc4.so => /usr/lib64/libplc4.so (0x00007fc9c8edb000)
	libplds4.so => /usr/lib64/libplds4.so (0x00007fc9c8ed6000)
	libpng16.so.16 => /usr/lib64/libpng16.so.16 (0x00007fc9c8e90000)
	libcairo-gobject.so.2 => /usr/lib64/libcairo-gobject.so.2 (0x00007fc9c8e86000)
	libepoxy.so.0 => /usr/lib64/libepoxy.so.0 (0x00007fc9c8d82000)
	libfribidi.so.0 => /usr/lib64/libfribidi.so.0 (0x00007fc9c8d63000)
	libharfbuzz.so.0 => /usr/lib64/libharfbuzz.so.0 (0x00007fc9c8cb5000)
	libpangoft2-1.0.so.0 => /usr/lib64/libpangoft2-1.0.so.0 (0x00007fc9c8c9d000)
	libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00007fc9c8c49000)
	libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007fc9c8b62000)
	libXinerama.so.1 => /usr/lib64/libXinerama.so.1 (0x00007fc9c8b5c000)
	libpixman-1.so.0 => /usr/lib64/libpixman-1.so.0 (0x00007fc9c8a48000)
	libEGL.so.1 => /usr/lib64/libEGL.so.1 (0x00007fc9c8a0c000)
	libxcb-shm.so.0 => /usr/lib64/libxcb-shm.so.0 (0x00007fc9c8a07000)
	libxcb-render.so.0 => /usr/lib64/libxcb-render.so.0 (0x00007fc9c89f7000)
	libGL.so.1 => /usr/lib64/libGL.so.1 (0x00007fc9c896e000)
	libgnutls.so.30 => /usr/lib64/libgnutls.so.30 (0x00007fc9c87be000)
	libavahi-common.so.3 => /usr/lib64/libavahi-common.so.3 (0x00007fc9c87b0000)
	libavahi-client.so.3 => /usr/lib64/libavahi-client.so.3 (0x00007fc9c879d000)
	libblkid.so.1 => /lib64/libblkid.so.1 (0x00007fc9c8742000)
	libbsd.so.0 => /usr/lib64/libbsd.so.0 (0x00007fc9c8725000)
	libgraphite2.so.3 => /usr/lib64/libgraphite2.so.3 (0x00007fc9c86fa000)
	libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fc9c86e3000)
	libxcb-dri2.so.0 => /usr/lib64/libxcb-dri2.so.0 (0x00007fc9c86dd000)
	libxcb-dri3.so.0 => /usr/lib64/libxcb-dri3.so.0 (0x00007fc9c86d7000)
	libxcb-xfixes.so.0 => /usr/lib64/libxcb-xfixes.so.0 (0x00007fc9c86cc000)
	libxcb-present.so.0 => /usr/lib64/libxcb-present.so.0 (0x00007fc9c86c8000)
	libxcb-sync.so.1 => /usr/lib64/libxcb-sync.so.1 (0x00007fc9c86bf000)
	libxshmfence.so.1 => /usr/lib64/libxshmfence.so.1 (0x00007fc9c86bc000)
	libgbm.so.1 => /usr/lib64/libgbm.so.1 (0x00007fc9c86ac000)
	libdrm.so.2 => /usr/lib64/libdrm.so.2 (0x00007fc9c8697000)
	libglapi.so.0 => /usr/lib64/libglapi.so.0 (0x00007fc9c8663000)
	libxcb-glx.so.0 => /usr/lib64/libxcb-glx.so.0 (0x00007fc9c8646000)
	libXxf86vm.so.1 => /usr/lib64/libXxf86vm.so.1 (0x00007fc9c863f000)
	libtasn1.so.6 => /usr/lib64/libtasn1.so.6 (0x00007fc9c8629000)
	libnettle.so.6 => /usr/lib64/libnettle.so.6 (0x00007fc9c85ea000)
	libhogweed.so.4 => /usr/lib64/libhogweed.so.4 (0x00007fc9c85ae000)
	libgmp.so.10 => /usr/lib64/libgmp.so.10 (0x00007fc9c8516000)
	libidn2.so.0 => /usr/lib64/libidn2.so.0 (0x00007fc9c84f7000)
	libunistring.so.2 => /usr/lib64/libunistring.so.2 (0x00007fc9c8378000)
Comment 1 marius.spix 2020-04-05 01:51:19 UTC
Adding the line

media-video/ffmpeg chromium

to /etc/portage/package.use and recompiling ffmpeg did not fix the problem.
Comment 2 marius.spix 2020-04-13 13:19:16 UTC
Created attachment 632654 [details]
strace output
Comment 3 marius.spix 2020-04-13 13:30:11 UTC
My system has 16 GB of memory. ulimit is unlimited. As you can see in the strace log, it seems that the last mprotect() call fails to reserve 143360 bytes.
Comment 4 marius.spix 2020-04-13 14:16:25 UTC
Updating to sys-libs/glibc-2.29-r7 did not change anything.
Comment 5 Marcin Woźniak 2020-05-02 19:51:16 UTC
I'm using the last version of discord (discord-canary). I made that ebuild.
Now I will put pull request for it ;)
Comment 6 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2020-09-12 01:12:11 UTC
Is this still happening?

If so, could you try with an earlier ffmpeg (<media-video/ffmpeg-4.3)?
Comment 7 marius.spix 2020-09-15 20:16:43 UTC
(In reply to Sam James from comment #6)
> Is this still happening?
> 
> If so, could you try with an earlier ffmpeg (<media-video/ffmpeg-4.3)?

I AM using media-video/ffmpeg-4.2.2 and the issue is still present.
Comment 8 marius.spix 2020-09-15 20:36:21 UTC
ldd says libffmpeg.so => not found

So I tried to compile media-video/ffmpeg with +chromium (which makes totally sense, because Discord is based on Electron, which is based on Chromium)

ldd STILL says libffmpeg.so => not found

Then I ran

echo LDPATH=/usr/lib64/chromium > /etc/env.d/99ffmpeg-chromium && env_update

It now finds /usr/lib64/chromium/libffmpeg.so

But it still segfaults.
Comment 9 marius.spix 2020-09-15 20:43:20 UTC
I also note that Discord comes with its own /opt/discord/ffmpeg.so
So I don't think that that ffmpeg is the issue.
Comment 10 marius.spix 2020-09-15 20:43:58 UTC
(In reply to marius.spix from comment #9)
> I also note that Discord comes with its own /opt/discord/ffmpeg.so
> So I don't think that that ffmpeg is the issue.

I meant /opt/discord/libffmpeg.so
Comment 11 Joakim Tjernlund 2020-10-07 17:38:53 UTC
Try adding to ffmpeg-4.3.x:
--- ./libavutil/mem.c.org	2020-10-07 19:22:30.286728200 +0200
+++ ./libavutil/mem.c	2020-10-07 19:24:04.039885660 +0200
@@ -71,6 +71,8 @@
 static size_t max_alloc_size= INT_MAX;
 
 void av_max_alloc(size_t max){
+    if (!max)
+        max = INT_MAX; /* be compatible to older < 4.3 versions */
     max_alloc_size = max;
 }
Comment 12 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2020-10-07 17:40:00 UTC
(In reply to marius.spix from comment #9)
> I also note that Discord comes with its own /opt/discord/ffmpeg.so
> So I don't think that that ffmpeg is the issue.

I don't have any great ideas then, yet. Does it work with upstream's original binary?
Comment 13 marius.spix 2020-10-07 20:38:01 UTC
(In reply to Sam James from comment #12)
> (In reply to marius.spix from comment #9)
> > I also note that Discord comes with its own /opt/discord/ffmpeg.so
> > So I don't think that that ffmpeg is the issue.
> 
> I don't have any great ideas then, yet. Does it work with upstream's
> original binary?

The ebuild loads the origina DEB package from upstream with the binaries.

(In reply to Joakim Tjernlund from comment #11)
> Try adding to ffmpeg-4.3.x:
> --- ./libavutil/mem.c.org	2020-10-07 19:22:30.286728200 +0200
> +++ ./libavutil/mem.c	2020-10-07 19:24:04.039885660 +0200
> @@ -71,6 +71,8 @@
>  static size_t max_alloc_size= INT_MAX;
>  
>  void av_max_alloc(size_t max){
> +    if (!max)
> +        max = INT_MAX; /* be compatible to older < 4.3 versions */
>      max_alloc_size = max;
>  }
I was using media-video/ffmpeg-4.2.2 and updated to 4.2.4. It still does not work.
Comment 14 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2020-10-07 20:40:41 UTC
(In reply to marius.spix from comment #13)
> (In reply to Sam James from comment #12)
> > (In reply to marius.spix from comment #9)
> > > I also note that Discord comes with its own /opt/discord/ffmpeg.so
> > > So I don't think that that ffmpeg is the issue.
> > 
> > I don't have any great ideas then, yet. Does it work with upstream's
> > original binary?
> 
> The ebuild loads the origina DEB package from upstream with the binaries.
> 

I'm asking to figure out if somehow we're doing anything weird. If it fails with upstream's binary, we need to report it there.
Comment 15 marius.spix 2020-10-07 20:58:26 UTC
(In reply to Sam James from comment #14)
> (In reply to marius.spix from comment #13)
> > (In reply to Sam James from comment #12)
> > > (In reply to marius.spix from comment #9)
> > > > I also note that Discord comes with its own /opt/discord/ffmpeg.so
> > > > So I don't think that that ffmpeg is the issue.
> > > 
> > > I don't have any great ideas then, yet. Does it work with upstream's
> > > original binary?
> > 
> > The ebuild loads the origina DEB package from upstream with the binaries.
> > 
> 
> I'm asking to figure out if somehow we're doing anything weird. If it fails
> with upstream's binary, we need to report it there.

It also makes no difference whether I use upstream’s libffmpeg.so or the libffmpeg.so from media-video/ffmpeg[chromium].
Comment 16 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2020-10-07 20:59:44 UTC
(In reply to marius.spix from comment #15)
> (In reply to Sam James from comment #14)
> > (In reply to marius.spix from comment #13)
> > > (In reply to Sam James from comment #12)
> > > > (In reply to marius.spix from comment #9)
> > > > > I also note that Discord comes with its own /opt/discord/ffmpeg.so
> > > > > So I don't think that that ffmpeg is the issue.
> > > > 
> > > > I don't have any great ideas then, yet. Does it work with upstream's
> > > > original binary?
> > > 
> > > The ebuild loads the origina DEB package from upstream with the binaries.
> > > 
> > 
> > I'm asking to figure out if somehow we're doing anything weird. If it fails
> > with upstream's binary, we need to report it there.
> 
> It also makes no difference whether I use upstream’s libffmpeg.so or the
> libffmpeg.so from media-video/ffmpeg[chromium].

I mean, if you use exactly upstream's binary from their .deb, extracted, does it work? If so, we can report it to them, because fixing segfaults isn't something that's easy for us to do in a closed-source pre-built binary.
Comment 17 marius.spix 2020-10-07 21:17:28 UTC
(In reply to Sam James from comment #16)
> (In reply to marius.spix from comment #15)
> > (In reply to Sam James from comment #14)
> > > (In reply to marius.spix from comment #13)
> > > > (In reply to Sam James from comment #12)
> > > > > (In reply to marius.spix from comment #9)
> > > > > > I also note that Discord comes with its own /opt/discord/ffmpeg.so
> > > > > > So I don't think that that ffmpeg is the issue.
> > > > > 
> > > > > I don't have any great ideas then, yet. Does it work with upstream's
> > > > > original binary?
> > > > 
> > > > The ebuild loads the origina DEB package from upstream with the binaries.
> > > > 
> > > 
> > > I'm asking to figure out if somehow we're doing anything weird. If it fails
> > > with upstream's binary, we need to report it there.
> > 
> > It also makes no difference whether I use upstream’s libffmpeg.so or the
> > libffmpeg.so from media-video/ffmpeg[chromium].
> 
> I mean, if you use exactly upstream's binary from their .deb, extracted,
> does it work? If so, we can report it to them, because fixing segfaults
> isn't something that's easy for us to do in a closed-source pre-built binary.

The segfault occurs in ld-2.30.so. See below:

[ 4793.255166] discord[10790]: segfault at 557cfc0bfd98 ip 00007f01d2a60f14 sp 00007ffd5c908ac0 error 6 in ld-2.30.so[7f01d2a56000+1e000]
[ 4793.255173] Code: 1f 80 00 00 00 00 48 8b 08 8b 50 08 4c 01 d1 48 83 fa 26 74 0a 48 83 fa 08 0f 85 fd 0f 00 00 48 8b 50 10 48 83 c0 18 4c 01 d2 <48> 89 11 48 39 c3 77 d4 e9 a4 fa ff ff 0f 1f 80 00 00 00 00 4c 89
Comment 18 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2020-10-07 21:30:42 UTC
(In reply to marius.spix from comment #8)
> ldd says libffmpeg.so => not found
> 
> So I tried to compile media-video/ffmpeg with +chromium (which makes totally
> sense, because Discord is based on Electron, which is based on Chromium)
> 
> ldd STILL says libffmpeg.so => not found
> 
> Then I ran
> 
> echo LDPATH=/usr/lib64/chromium > /etc/env.d/99ffmpeg-chromium && env_update
> 
> It now finds /usr/lib64/chromium/libffmpeg.so
> 
> But it still segfaults.

Right. So if you try this, but instead adding /opt/discord-bin/ to help it find the bundled ffmpeg, does *that* work?

If the segfault is in ld.so, it's hard to see much else it could be other than crying when it can't find the (right) library.
Comment 19 marius.spix 2020-10-07 21:37:56 UTC
(In reply to Sam James from comment #18)
> (In reply to marius.spix from comment #8)
> > ldd says libffmpeg.so => not found
> > 
> > So I tried to compile media-video/ffmpeg with +chromium (which makes totally
> > sense, because Discord is based on Electron, which is based on Chromium)
> > 
> > ldd STILL says libffmpeg.so => not found
> > 
> > Then I ran
> > 
> > echo LDPATH=/usr/lib64/chromium > /etc/env.d/99ffmpeg-chromium && env_update
> > 
> > It now finds /usr/lib64/chromium/libffmpeg.so
> > 
> > But it still segfaults.
> 
> Right. So if you try this, but instead adding /opt/discord-bin/ to help it
> find the bundled ffmpeg, does *that* work?
> 
> If the segfault is in ld.so, it's hard to see much else it could be other
> than crying when it can't find the (right) library.



As I already mentioned, both libffmpeg do not work.



An interesting discovery in the strace output:

At the begin 143360 bytes are allocation ...
mmap(0x7f2f49721000, 143360, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2b0000) = 0x7f2f49721000

... and later write-protected ...
mprotect(0x7f2f49721000, 143360, PROT_READ) = 0

... just after that mprotect call, a segfault at the address 0x556dd86c7d98 occurs, which was never allocated. I wonder where this address comes from. I tested it several times. While the first address is always matches the pattern 0x7fexxxxxx000 or 0x7ffxxxxxx000, the other address always matches 0x55xxxxxxxd98 or 0x56xxxxxxxd98. I don’t know if this is relevant, but is was noticeable and I wonder, where the latter address comes from.
Comment 20 marius.spix 2020-10-07 21:53:09 UTC
Created attachment 664258 [details]
Valgrind output
Comment 21 whitleystriber 2020-12-04 21:41:51 UTC
I had this segfault issue for the longest time on the 16.1 profile. I just recently reformatted and reinstalled Gentoo from scratch after a botched 16.1 -> 17.0 upgrade. After installing Discord, I have not had one segfault. I still do not know what causes this but I hope this helps someone who was as frustrated as I was.
Comment 22 marius.spix 2020-12-04 22:01:01 UTC
It works for me now after I updated to sys-devel/binutils-2.34-r2
Comment 23 Randall 2022-05-26 15:13:13 UTC
Discord now includes its own `libffmpeg.so` that requires use. 

As a side note, not all electron apps can use system libs. FME, most of them prefer to use the libs they're distributed with.

Regardless, I'm closing this as this seems to have been addressed by upstream now including its own `libffmpeg.so` and the updated ebuild uses it.