#244 closed defect (invalid)
0.8.1: "segmentation fault" on connect
| Reported by: | onlyjob | Owned by: | Antoine Martin |
|---|---|---|---|
| Priority: | blocker | Milestone: | 0.8 |
| Component: | core | Version: | trunk |
| Keywords: | Cc: |
Description
xpra-0.8.1 client can't attach to any sessions -- it crashes with error "Segmentation fault" immediately after printing "Attached to...".
Using client 0.7.8 I can connect to session started with 0.8.1 but 0.8.1 is unable to connect neither to 0.7.8 nor to 0.8.1.
Here is the client-side log (-d all):
2013-02-04 09:44:29,228 ping echo server load=(5280, 4980, 4710), measured client latency=18ms
2013-02-04 09:44:29,272 window types=('_NET_WM_WINDOW_TYPE_NORMAL',)
2013-02-04 09:44:29,490 window types=('_NET_WM_WINDOW_TYPE_NORMAL',)
2013-02-04 09:44:30,034 new cursor at 5,0 with serial=15, dimensions: 24x24, len(pixels)=2304
2013-02-04 09:44:30,035 new cursor at 7,7 with serial=1, dimensions: 16x16, len(pixels)=1024
2013-02-04 09:44:30,037 Got configure event: <gtk.gdk.Event at 0x3074508: GDK_CONFIGURE x=41, y=92, width=1280, height=737>
2013-02-04 09:44:30,345 xget_u32_property(<gtk.gdk.Window object at 0x300dbe0 (GdkWindow at 0x2dd8360)>, _NET_WM_DESKTOP)=0
2013-02-04 09:44:30,357 Got map event: <gtk.gdk.Event at 0x3074508: GDK_MAP>
2013-02-04 09:44:30,357 set_workspace() workspace=0
2013-02-04 09:44:30,407 xget_u32_property(<gtk.gdk.Window object at 0x302b6e0 (GdkWindow at 0x2dd8360)>, _NET_WM_DESKTOP)=0
2013-02-04 09:44:30,416 _focus_change((<ClientWindow object at 0x302b690 (xpra+client_window+ClientWindow at 0x30d10a0)>, <GParamBoolean 'has-toplevel-focus'>))
2013-02-04 09:44:30,416 update_focus(1,True) _focused=None
2013-02-04 09:44:30,417 Got configure event: <gtk.gdk.Event at 0x3074508: GDK_CONFIGURE x=41, y=92, width=1280, height=737>
2013-02-04 09:44:30,418 xget_u32_property(<gtk.gdk.Window object at 0x302b6e0 (GdkWindow at 0x2dd8360)>, _NET_WM_DESKTOP)=0
2013-02-04 09:44:30,419 Got configure event: <gtk.gdk.Event at 0x3074508: GDK_CONFIGURE x=41, y=92, width=1194, height=531>
2013-02-04 09:44:30,420 xget_u32_property(<gtk.gdk.Window object at 0x302b6e0 (GdkWindow at 0x2dd8480)>, _NET_WM_DESKTOP)=0
2013-02-04 09:44:30,428 Got map event: <gtk.gdk.Event at 0x3074508: GDK_MAP>
2013-02-04 09:44:30,428 set_workspace() workspace=0
2013-02-04 09:44:30,707 xget_u32_property(<gtk.gdk.Window object at 0x302baf0 (GdkWindow at 0x2dd8480)>, _NET_WM_DESKTOP)=0
Segmentation fault
Attachments (1)
Change History (18)
comment:1 Changed 8 years ago by
comment:2 Changed 8 years ago by
It is an issue (regression?) with libav-9.1.
I just found that libav-0.8.5 works...
comment:3 follow-up: 4 Changed 8 years ago by
| Owner: | set to Antoine Martin |
|---|---|
| Status: | new → accepted |
It does sound likely, there is nothing in 0.8.1 related to x264 directly:
- r2628, r2631 are in the UI
- r2629, r2636 are packaging related
- r2630 is sound
- r2632 and r2638 revert 0.8 changes
- r2633 is x264 auto-refresh related (only makes it fire more)
- r2634 disabled tray forwarding in defaults
- r2635 is the pulseaudio upgrade fix
But, if this was libav related then it should affect all versions that link against it.. Will try to test.
This is on Debian sid amd64 right?
comment:4 Changed 8 years ago by
Yes, this is nothing related to 0.8.1 specifically.
To double-check I re-built 0.7.8 with new libav-9.1 ang experience the similar crash.
Yes, Debian "unstable" but libav-9.1 is only available form "experimental" at this time while we're in freeze.
I filed bug
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699722
hopefully we will get some feedback.
comment:5 Changed 8 years ago by
| Resolution: | → invalid |
|---|---|
| Status: | accepted → closed |
Confirmed as a libav bug, I was seeing memory allocation these errors on mac osx:
Non-aligned pointer being freed
as per non-aligned pointer being freed on mac
Downgrading to libav 0.8.5 fixes the issue, I've added a warning to the osx build page: https://winswitch.org/trac/changeset/5141
Not an xpra bug, closing.
comment:6 Changed 8 years ago by
From http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699722#27
From: Reinhard Tartler <siretart@…>
To: Dmitry Smirnov <onlyjob@…>, 699722@…
Cc: Anton Khirnov <anton@…>
Subject: Re: Bug#699722: src:libav: x264 decoding crashes
Date: Tue, 5 Feb 2013 07:51:47 +0100
On Tue, Feb 5, 2013 at 2:10 AM, Dmitry Smirnov <onlyjob@…> wrote:
This is happening only when I build xpra with the following packages from experimental:
libavcodec-dev libavutil-dev libswscale-dev libswscale2
Merely upgrading libswscale2 doesn't break x264 encoding.
OK, I've checked with libav upstream, but I'm a bit in hurry right
now. Please have a look at the irc chatlog. In short, xpra is buggy,
and Anton (email in CC) is even proposing a patch to fix xpra:
07:20 <siretart> elenril: can you make any sense out of
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699722#17 ? -
Thread 2, frame
#6indicates that
avcodec_get_frame_defaults() frees (via av_freep) a pointer that it
shouldn't free.
07:22 <siretart> elenril: submitter claims that downgrading to 0.8.5
avoids the crash. now I wonder if the fault is on
our, or on the xpra side
07:26 <elenril> it's probably old x264 version with a new libav version
07:26 <elenril> x264 used to abuse our api, that particular way of
abuse got broken
07:30 <siretart> elenril: on that case, we probably should require a
new-enough x264 version in configure. or at least warn about it. what
do you think?
07:31 <siretart> the package in question is running libx264 0.129.2238
07:31 <siretart> is this too old?
07:31 <siretart> elenril:
07:33 <siretart> build 129 is the newest version available, so I'm not
entirely convinced by your theory
07:34 <elenril> see 6e68ab73908f339cdd91c40943fef46fd1f832fa in x264
07:35 <elenril> and i don't see how _us_ requiring a specific libx264
solves anything
07:35 <elenril> the problem is x264 calling libav
07:35 <elenril> not libav calling x264
07:35 <elenril> and that package appears to contain embedded x264
07:35 <elenril> isn't that evil?
07:39 <elenril> hmm...no
07:39 <elenril> but it abuses our api in exactly the same way
07:40 <elenril> it has an uninitialized AVFrame on stack
07:40 <siretart> looking
07:42 <siretart> elenril: hm, the submitter does use a libx264 that
has this patch included
07:43 <siretart> elenril: or do you imply that even with
6e68ab73908f339cdd91c40943fef46fd1f832fa, libx264 is still bugged?
07:43 <elenril> see the last three lines i said
07:44 <siretart> ok, what does "it has an uninitialized AVFrame on
stack" now mean? is the application responsible for having it properly
allocated? don't we have
an allocation API that DTRT?
07:45 <elenril> http://paste.debian.net/231849/
07:45 <elenril> here's a fixed version
07:46 <siretart> fixed version of what?
07:46 <elenril> of the broken file in xpra
07:46 <elenril> let me make a patch
07:48 <elenril> http://paste.debian.net/231850/
Cheers,
--
regards,
Reinhard
comment:7 Changed 8 years ago by
From http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699722#32
From: anton@…
To: 699722@…
Subject: Re: Bug#699722: src:libav: x264 decoding crashes
Date: Tue, 05 Feb 2013 08:03:56 +0100
[Message part 1 (text/plain, inline)]
Hi,
a Libav developer here.
This is really a bug/abuse of Libav API in xpra -- the file x264lib.c uses an
uninitialized AVFrame on stack. This has always been forbidden by Libav API, but
used to work until some changes a few months ago. Functions
avcodec_alloc_frame() and avcodec_free_frame() (in release 9 only, av_free() in
0.8 and earlier) must be used to allocate and free an AVFrame.
Attached is a patch that fixes it.
--
Anton Khirnov
Changed 8 years ago by
| Attachment: | xpra-fix-new-libav.patch added |
|---|
comment:8 Changed 8 years ago by
Full crash backtrace is there: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699722#17
comment:12 Changed 8 years ago by
FYI: avcodec_free_frame does not exist in the Debian Squeeze version of libav... PITA, so while we have fixed "experimental", we have also broken something else - and likely other distros too. Not ideal..
comment:13 Changed 8 years ago by
But it work with libav-8.5 right?
Then just take it's as notice for dropping support for old systems. :)
Xpra in Squeeze is available from official backports (ver. 0.3.11) which by the way doesn't have x264 enabled at all (I'm talking about official Debian Xpra package). x264 never worked well enough until 0.7.x at least not in Squeeze and Lucid. Perhaps it would be better to stop wasting time and effort for compatibility with those old systems and focus on development priorities?
comment:14 Changed 8 years ago by
With older systems, one can use av_free instead:
/** * Allocates an AVFrame and sets its fields to default values. The resulting * struct can be deallocated by simply calling av_free(). * * @return An AVFrame filled with default values or NULL on failure. * @see avcodec_get_frame_defaults */ AVFrame *avcodec_alloc_frame(void);
Just means I need a patch for squeeze builds :(
As for "official backports" - that thing is scary/buggy/insecure, anyone running v0.3.x should be aware of that. At least the builds I provide aren't.
I would be glad to stop making them, but Debian isn't being diligent there.
comment:15 Changed 8 years ago by
No, within Debian release cycle we've made almost impossible with squeezing all the updates that we could get through. The alternative could be to request removal of Xpra from Wheezy and maintain it through backports. That's an option.
0.3.x was good enough for its time and just because we have a newer version now it doesn't mean we need to wipe old release that was proven to be OK for release.
You're releasing very fast to catch up with you and not without bumps like 0.8.0 which is great but couldn't be released to Debian as is without week of work and testing. Stability means that time proves how good release is going to be. Sometimes too fresh is not better than old with know caveats.
I was very diligent to improve Xpra as much as possible for Debian. I doubt it could be done much better than I did...
comment:16 Changed 8 years ago by
Like I said, an "OK for release" would be a "NOT OK for having installed" if people were aware of just how buggy and crash prone it is (and I suspect there may well be a few security issues in there too - I can't remember if the actual 0.3.x version shipped has them or not)
TBH, I do not really care/have time to consider Debian freezes and policies (or other distros for that matter), especially when it gets in the way of ensuring users have a reliable version of the software available - which seems to be the problem here.
BTW, I am not criticising you or even asking for 0.8 to be packaged for any specific version of Debian, all I am saying is that no-one should be running 0.3.x right now. I very much regret making this 0.3.x stable branch since some never moved on when it got abandoned - that was not the point. Choosing a version and a default encoding to use is a valid question, sticking with 0.3.x because of "policy" is not (or maybe the "policy" is wrong - not for me to decide)
If you want to continue this discussion, let's use email or the mailing list. This bug is now closed: I am in the process of testing 0.8.2 beta builds for all releases with this patch: r2673 (ok so far)
comment:17 Changed 8 years ago by
FWIW: this caused many older distros to completely break - despite the "old-libav.patch", simply using av_free is not enough, see #271
copyleft 2010 - 2020
Client 0.7.8 is crashing when I change encoding to x264 when connected to server 0.8.1 using client 0.7.8: