Bug#948658: qemu: Qemu 4.2 hangs/freezes completely due to audio backend changes [regression][bisected]
On Sun, 26 Jul 2020, Michael Tokarev wrote: [ https://bugs.debian.org/948658 ] Hi Matti! Is this problem with audio input still exist with current version of qemu in testing, the 5.0 one? Thanks! /mjt Yes, the hang is still reproducible with 5.0-13, but I've been using the workaround I described in previous mails, e.g. NOT setting 'QEMU_ALSA_ADC_DEV="null"', even though that results in numerous warning messages .. but works without hanging. -- ] ccr/TNSP ^ pWp :: c...@tnsp.org :: https://tnsp.org/~ccr/ ] https://tnsp.org/hg/ -- https://www.openhub.net/accounts/ccr ] PGP key: 7BED 62DE 898D D1A4 FC4A F392 B705 E735 307B AAE3
Bug#961362: fonts-terminus-otb: In rxvt-unicode, M and m characters missing the left vertical stroke
Hello, I ran into this problem myself (using "URxvt*font: xft:Terminus:pixelsize=20" font spec), and seems it is some kind of bug in rxvt-unicode. Xterm does not suffer from this issue with the same font spec. The issue seems to reside in src/rxvtfont.C rxvt_font_xft::draw() with the doublebuffered rendering, if you disable buffering via "URxvt*buffered: false", the issue disappears at least for my use case. But, disabling buffering is probably not a very efficient solution. Also a kludge-patching line 1380 of src/rxvtfont.C: - int x_ = buffered ? 0 : x; + int x_ = buffered ? 1 : x; "fixes" the issue as well at least for the case I bothered to check, but obviously that's not a good solution either. Perhaps this issue should be transferred to package rxvt-unicode? -- ] ccr/TNSP ^ pWp :: c...@tnsp.org :: https://tnsp.org/~ccr/ ] https://tnsp.org/hg/ -- https://www.openhub.net/accounts/ccr ] PGP key: 7BED 62DE 898D D1A4 FC4A F392 B705 E735 307B AAE3
Bug#949246: wine32:i386: Running Fallout 1 or 2 under Wine 5.0~rc2-1 fullscreen results in black image [regression]
On Sat, 18 Jan 2020, Michael Gilbert wrote: control: tag -1 moreinfo control: severity -1 minor On Sat, Jan 18, 2020 at 3:35 PM Matti Hamalainen wrote: "virtual desktop" works, but is not a feasible option as on a 2560x1440 screen a 640x480 resolution game will be minuscule. winecfg can be used to change dimensions of the virtual desktop. True, but that does not make it actual fullscreen, and the game changes the "virtual desktop" size anyway, because it has no windowed mode. Kernel: Linux 5.4.12-qcmm (SMP w/8 CPU cores) Can this be reproduced with a vanilla debian kernel? Yes. Exactly same symptom on linux-image-5.4.0-2-amd64 -- ] ccr/TNSP ^ pWp :: c...@tnsp.org :: https://tnsp.org/~ccr/ ] https://tnsp.org/hg/ -- https://www.openhub.net/accounts/ccr ] PGP key: 7BED 62DE 898D D1A4 FC4A F392 B705 E735 307B AAE3
Bug#948658: qemu: Qemu 4.2 hangs/freezes completely due to audio backend changes [regression][bisected]
Hello!
After some more digging, I've tracked the problem to the audio input /
capture-side of the code. If I leave out the QEMU_ALSA_ADC_DEV="null"
environment variable, the freeze does not happen, but Qemu spews
hundreds of errors, following lines repeat many times:
--
alsa: Could not initialize ADC
alsa: Failed to open `default':
alsa: Reason: No such file or directory
alsa: Could not initialize ADC
alsa: Failed to open `default':
alsa: Reason: No such file or directory
audio: Failed to create voice `adc'
--
I also tried disabling the capture in the code, with this patch against
v4.2.0 git. (You also have to pass --disable-werror to configure.)
diff --git a/audio/audio.c b/audio/audio.c
index 56fae55047..82476a41de 100644
--- a/audio/audio.c
+++ b/audio/audio.c
@@ -1352,8 +1352,10 @@ static void audio_run_capture (AudioState *s)
void audio_run(AudioState *s, const char *msg)
{
audio_run_out(s);
+#if 0
audio_run_in(s);
audio_run_capture(s);
+#endif
#ifdef DEBUG_POLL
{
.. and with the patch it worked perfectly. No hangs/freeze. But obviously
it is not a solution for other people as it disables audio capture/recording.
Personally I don't need it, of course, which is why I have that
QEMU_ALSA_ADC_DEV="null" set.
Hope this helps.
--
] ccr/TNSP ^ pWp :: c...@tnsp.org :: https://tnsp.org/~ccr/
] https://tnsp.org/hg/ -- https://www.openhub.net/accounts/ccr
] PGP key: 7BED 62DE 898D D1A4 FC4A F392 B705 E735 307B AAE3
Bug#948658: qemu: Qemu 4.2 hangs/freezes completely due to audio backend changes [regression][bisected]
Attaching a full 'thread apply all bt' backtrace of all the Qemu threads in the hang/freeze situation, just in case. -- ] ccr/TNSP ^ pWp :: c...@tnsp.org :: https://tnsp.org/~ccr/ ] https://tnsp.org/hg/ -- https://www.openhub.net/accounts/ccr ] PGP key: 7BED 62DE 898D D1A4 FC4A F392 B705 E735 307B AAE3 Thread 11 (Thread 0x7f94b65ff700 (LWP 232454)): #0 0x7f94d6e49d1f in __GI___poll (fds=0x7f91980031e0, nfds=2, timeout=2147483647) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x7f94d7d3210e in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7f94d7d32473 in g_main_loop_run () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7f94d75a39e7 in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 #4 0x7f94d6f24fb7 in start_thread (arg=) at pthread_create.c:486 #5 0x7f94d6e542df in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 10 (Thread 0x7f94b6ffd700 (LWP 232453)): #0 0x7f94d6f2e01c in __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:103 #1 0x7f94d6f27764 in __GI___pthread_mutex_lock (mutex=mutex@entry=0x557971faf380 ) at ../nptl/pthread_mutex_lock.c:80 #2 0x557971a5d073 in qemu_mutex_lock_impl (mutex=0x557971faf380 , file=0x557971a86fb8 "/build/qemu-Mzf7Xr/qemu-4.2/accel/kvm/kvm-all.c", line=2415) at ./util/qemu-thread-posix.c:78 #3 0x55797160d3ee in qemu_mutex_lock_iothread_impl (file=file@entry=0x557971a86fb8 "/build/qemu-Mzf7Xr/qemu-4.2/accel/kvm/kvm-all.c", line=line@entry=2415) at ./cpus.c:1899 #4 0x55797162b357 in kvm_cpu_exec (cpu=cpu@entry=0x5579727078a0) at ./accel/kvm/kvm-all.c:2415 #5 0x55797160d63e in qemu_kvm_cpu_thread_fn (arg=0x5579727078a0) at ./cpus.c:1318 #6 0x55797160d63e in qemu_kvm_cpu_thread_fn (arg=arg@entry=0x5579727078a0) at ./cpus.c:1290 #7 0x557971a5ce7b in qemu_thread_start (args=) at ./util/qemu-thread-posix.c:519 #8 0x7f94d6f24fb7 in start_thread (arg=) at pthread_create.c:486 #9 0x7f94d6e542df in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 9 (Thread 0x7f94b77fe700 (LWP 232452)): #0 0x7f94d6f2e01c in __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:103 #1 0x7f94d6f27764 in __GI___pthread_mutex_lock (mutex=mutex@entry=0x557971faf380 ) at ../nptl/pthread_mutex_lock.c:80 #2 0x557971a5d073 in qemu_mutex_lock_impl (mutex=0x557971faf380 , file=0x557971a7a008 "/build/qemu-Mzf7Xr/qemu-4.2/exec.c", line=3093) at ./util/qemu-thread-posix.c:78 #3 0x55797160d3ee in qemu_mutex_lock_iothread_impl (file=file@entry=0x557971a7a008 "/build/qemu-Mzf7Xr/qemu-4.2/exec.c", line=line@entry=3093) at ./cpus.c:1899 #4 0x5579715c5879 in prepare_mmio_access (mr=, mr=) at ./exec.c:3093 #5 0x5579715cab07 in flatview_read_continue (fv=fv@entry=0x7f94ac7374f0, addr=addr@entry=4275044592, attrs=..., buf=buf@entry=0x7f94d4ddf028 "\256}V\253", len=len@entry=4, addr1=, l=, mr=0x557972e12540) at ./exec.c:3189 #6 0x5579715cad43 in flatview_read (fv=0x7f94ac7374f0, addr=4275044592, attrs=..., buf=0x7f94d4ddf028 "\256}V\253", len=4) at ./exec.c:3230 #7 0x5579715cae5b in address_space_read_full (as=, addr=, attrs=..., buf=, len=) at ./exec.c:3243 #8 0x5579715caf65 in address_space_rw (as=, addr=, attrs=..., attrs@entry=..., buf=buf@entry=0x7f94d4ddf028 "\256}V\253", len=, is_write=) at ./exec.c:3271 #9 0x55797162b478 in kvm_cpu_exec (cpu=cpu@entry=0x5579726dfe00) at ./accel/kvm/kvm-all.c:2360 #10 0x55797160d63e in qemu_kvm_cpu_thread_fn (arg=0x5579726dfe00) at ./cpus.c:1318 #11 0x55797160d63e in qemu_kvm_cpu_thread_fn (arg=arg@entry=0x5579726dfe00) at ./cpus.c:1290 #12 0x557971a5ce7b in qemu_thread_start (args=) at ./util/qemu-thread-posix.c:519 #13 0x7f94d6f24fb7 in start_thread (arg=) at pthread_create.c:486 #14 0x7f94d6e542df in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 8 (Thread 0x7f94b7fff700 (LWP 232451)): #0 0x7f94d6f2e01c in __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:103 #1 0x7f94d6f27764 in __GI___pthread_mutex_lock (mutex=mutex@entry=0x557971faf380 ) at ../nptl/pthread_mutex_lock.c:80 #2 0x557971a5d073 in qemu_mutex_lock_impl (mutex=0x557971faf380 , file=0x557971a86fb8 "/build/qemu-Mzf7Xr/qemu-4.2/accel/kvm/kvm-all.c", line=2415) at ./util/qemu-thread-posix.c:78 #3 0x55797160d3ee in qemu_mutex_lock_iothread_impl (file=file@entry=0x557971a86fb8 "/build/qemu-Mzf7Xr/qemu-4.2/accel/kvm/kvm-all.c", line=line@entry=2415) at ./cpus.c:1899 #4 0x55797162b357 in kvm_cpu_exec (cpu=cpu@entry=0x5579726b8360) at ./accel/kvm/kvm-all.c:2415 #5 0x55797160d63e in qemu_kvm_cpu_thread_fn (arg=0x5579726b8360) at ./cpus.c:1318 #6 0x55797160d63e in qemu_kvm_cpu_thread_fn (arg=arg@entry=0x5579726b8360) at ./cpus.c:1290 #7 0x557971a5ce7b in qemu_thread_start (args=) at ./util/qemu-thread-posix.c:519 #8 0x7f94d6f24fb7 in start_thread (arg=) at
Bug#948658: qemu: Qemu 4.2 hangs/freezes completely due to audio backend changes [regression][bisected]
Did some additional testing, it seems that the QEMU_AUDIO_DAC_TRY_POLL=0
I mentioned previously is not needed with Qemu 4.1, but I'm sure it was
needed with an older Qemu version, I could not get any sound with
the ALSA+dmix config I have without it back then.
In any case, I tested Qemu 4.1.1 built from git, and 4.2-1 Debian package
and this setting seems to have no bearing on the hang/freeze.
and I also disabled the ALSA dmix configuration to test that case,
using only basic /etc/asound.conf like this:
# cat asound.conf
pcm.!default {
type hw
card 1
}
ctl.!default {
type hw
card 1
}
and the freeze/hang happens even with that. So it's probably not the
dmix's fault either. :| Doing GDB bt gives the same backtrace, too.
Not sure what else to test, really.
--
] ccr/TNSP ^ pWp :: c...@tnsp.org :: https://tnsp.org/~ccr/
] https://tnsp.org/hg/ -- https://www.openhub.net/accounts/ccr
] PGP key: 7BED 62DE 898D D1A4 FC4A F392 B705 E735 307B AAE3
Bug#948658: qemu: Qemu 4.2 hangs/freezes completely due to audio backend changes [regression][bisected]
On Tue, 14 Jan 2020, Michael Tokarev wrote: Can you please try one more thing here, - namely, getting a backtrace? Qemu being unresponsible means it is the main thread which is blocked, so getting a backtrace should be easy - please install the qemu-system-x86 debug package (after adding something like this to sources.list: deb http://deb.debian.org/debian-debug/ stable-debug main , see https://wiki.debian.org/AutomaticDebugPackages), and get a backtrace using gdb, like this: gdb /usr/bin/qemu-system-x86_64 -p and do a `bt' command in there, posting the results from it. Thank you! Of course, should've thought of that myself actually :) (gdb) bt #0 0x55adc699e86c in conv_natural_int16_t_to_stereo (dst=, src=, samples=) at ./audio/mixeng_template.h:110 #1 0x55adc699b4b9 in audio_pcm_hw_run_in (samples=18446744048139465969, hw=0x55adca24ec20) at ./audio/audio.c:1249 #2 0x55adc699b4b9 in audio_run_in (s=0x55adca249330) at ./audio/audio.c:1280 #3 0x55adc699b4b9 in audio_run (s=0x55adca249330, msg=msg@entry=0x55adc6d04098 "alsa run (running)") at ./audio/audio.c:1355 #4 0x55adc69a0988 in alsa_poll_handler (opaque=0x55adca24ecc0) at ./audio/alsaaudio.c:203 #5 0x55adc6c93ed7 in aio_dispatch_handlers (ctx=ctx@entry=0x55adc92400c0) at ./util/aio-posix.c:429 #6 0x55adc6c948a8 in aio_dispatch (ctx=0x55adc92400c0) at ./util/aio-posix.c:460 #7 0x55adc6c9117e in aio_ctx_dispatch (source=, callback=, user_data=) at ./util/async.c:260 #8 0x7f99c123df1d in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #9 0x55adc6c93948 in glib_pollfds_poll () at ./util/main-loop.c:219 #10 0x55adc6c93948 in os_host_main_loop_wait (timeout=) at ./util/main-loop.c:242 #11 0x55adc6c93948 in main_loop_wait (nonblocking=) at ./util/main-loop.c:518 #12 0x55adc6994e0e in main_loop () at ./vl.c:1810 #13 0x55adc67fb0c9 in main (argc=, argv=, envp=) at ./vl.c:4466 (gdb) I also forgot to note down some other important information, namely the commandline options and config plus few quite related environment variables .. the commandline is qemu-system-x86_64 --enable-kvm -readconfig test.config -soundhw hda -vga qxl -display gtk contents of test.config attached. I have the following environment variables set in my script that runs qemu: export QEMU_AUDIO_DAC_TRY_POLL=0 export QEMU_AUDIO_DRV="alsa" export QEMU_ALSA_ADC_DEV="null" That DAC_TRY_POLL=0 was essential to get things working with dmix, DRV is obvious, ADC I've set just null because I'm not using mic or anything. Hopefully this helps. I should probably fiddle around and test some more, but have been a bit busy with other things. -- ] ccr/TNSP ^ pWp :: c...@tnsp.org :: https://tnsp.org/~ccr/ ] https://tnsp.org/hg/ -- https://www.openhub.net/accounts/ccr ] PGP key: 7BED 62DE 898D D1A4 FC4A F392 B705 E735 307B AAE3# qemu config file [drive] driver = "raw" file = "/misc/virtual/test.img" if = "virtio" [device] driver = "usb-tablet" [nic] type = "user" model = "virtio-net-pci" [rtc] base = "localtime" clock = "host" [machine] accel = "kvm" usb = "on" [memory] size = "12G" [smp-opts] cpus = "8" sockets = "1" cores = "4" threads = "2"
Bug#897059: (no subject)
Hello, Submitted a report to libgphoto2 Github issue tracker: https://github.com/gphoto/libgphoto2/issues/265 -- ] ccr/TNSP ^ pWp :: c...@tnsp.org :: https://tnsp.org/~ccr/ ] https://tnsp.org/hg/ -- https://www.openhub.net/accounts/ccr ] PGP key: 7BED 62DE 898D D1A4 FC4A F392 B705 E735 307B AAE3
Bug#897059: [Pkg-phototools-devel] Bug#897059: libgphoto2-6: libgphoto2 causes corrupted image file transfers
On Sat, 28 Apr 2018, Herbert Fortes wrote: Em 27-04-2018 21:26, Matti Hämäläinen escreveu: Hello, I tested against the current upstream GIT version (91a8425a4fa27def793fa9db2bcb4a71c26c927b) of libgphoto2, and the problem exists there as well. If gphoto debug logs are needed, I can provide ones against working 2.5.16 and non-working, but they are rather large (about 100M uncompressed each, 75M both tar+xz'd). I think the problem is that you are using gphoto2 version 2.5.16 with libgphoto2 version 2.5.17. There is a gphoto2 version 2.5.17. I forgot to upload it. :(. I am really sorry about that. I am starting to do the pachage now. Sorry to bring bad news, but I now tested gphoto2 from GIT (with GIT libgphoto2) as well, and the problem persists with that. :( -- [ .. LD_LIBRARY_PATH=/opt/lib ] $ /opt/bin/gphoto2 --version gphoto2 2.5.17.1 Copyright (c) 2000-2018 Lutz Mueller and others gphoto2 comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of gphoto2 under the terms of the GNU General Public License. For more information about these matters, see the files named COPYING. This version of gphoto2 is using the following software versions and options: gphoto2 2.5.17.1 gcc, popt(m), exif, no cdk, no aa, jpeg, readline libgphoto2 2.5.17.1 all camlibs, gcc, ltdl, EXIF libgphoto2_port 0.12.0 iolibs: disk ptpip serial usb1 usbdiskdirect usbscsi, gcc, ltdl, USB, serial without locking I wrote a short shell script for testing, https://tnsp.org/~ccr/gphoto2/testgphoto.sh probably not useful, but who knows. :) If more information is needed, I can try things out. Matti -- ] ccr/TNSP ^ pWp :: c...@tnsp.org :: https://tnsp.org/~ccr/ ] https://tnsp.org/hg/ -- https://www.openhub.net/accounts/ccr ] PGP key: 7BED 62DE 898D D1A4 FC4A F392 B705 E735 307B AAE3
Bug#897059: libgphoto2-6: libgphoto2 causes corrupted image file transfers
Hello, I tested against the current upstream GIT version (91a8425a4fa27def793fa9db2bcb4a71c26c927b) of libgphoto2, and the problem exists there as well. If gphoto debug logs are needed, I can provide ones against working 2.5.16 and non-working, but they are rather large (about 100M uncompressed each, 75M both tar+xz'd). Thanks in advance. -- ] ccr/TNSP ^ pWp :: c...@tnsp.org :: https://tnsp.org/~ccr/ ] https://tnsp.org/hg/ -- https://www.openhub.net/accounts/ccr ] PGP key: 7BED 62DE 898D D1A4 FC4A F392 B705 E735 307B AAE3
Bug#225514: (no subject)
Not reproducible anymore, is tagged fixed-upstream and is extremely old. I suggest this can be closed. -- ] ccr/TNSP ^ pWp :: ccr tnsp org :: http://tnsp.org/~ccr/ ] PGP key: 7BED 62DE 898D D1A4 FC4A F392 B705 E735 307B AAE3
Bug#816993: wmaker: versions > 0.95.6-1.2 break some fullscreen applications (DOSBox, quakeforge, vavoom)
Hello again! After some more detective work, I noticed that the issue did not occur on self-compiled WindowMaker from the git-repo, which made me think what the debian packaged version might be doing differently ... It turns out that the deb passes "--enable-randr" flag to wmaker configure, which is the root cause of this issue. The option flag is marked "enable RandR extension support (NOT recommended, buggy)". Doing a rebuild of the package with edited debian/rules that has --enable-randr removed fixes the problem. It seems that the flag was enabled in this change: https://anonscm.debian.org/git/pkg-wmaker/wmaker.git/commit/debian/rules?id=e737a261679e2db0ae80c8087302f88d8569859a -- ] ccr/TNSP ^ pWp :: ccr tnsp org :: http://tnsp.org/~ccr/ ] PGP key: 7BED 62DE 898D D1A4 FC4A F392 B705 E735 307B AAE3
Bug#816993: (no subject)
Hi, It seems that the programs that trigger/suffer from this bug are all using libSDL 1.2. The way libSDL 2.0 (and few other programs that I tested, like Stellarium) handle fullscreen seems to be different and are not affected. However, as the problems are not exhibited when using Wmaker 0.95.6-1.2 OR, for example OpenBox WM, I'm not sure if the finger of blame can be solely pointed towards libSDL 1.2. In any case, I hope this helps. -- ] ccr/TNSP ^ pWp :: ccr tnsp org :: http://tnsp.org/~ccr/ ] PGP key: 7BED 62DE 898D D1A4 FC4A F392 B705 E735 307B AAE3
Bug#691301: abiword: Abiword segfaults, dumps core
Hi!
After apt-getting the Abiword source and doing some poking around, I
finally managed to uncover what the problem was and it is a bit silly.
As background information, I semi-recently converted my system from
ISO-8859-1 to using UTF-8 unicode, but apparently I had forgotten to
change the user name/comment fields in /etc/passwd, and those entries
were still using some 8-bit ISO-8859-1 accented characters.
Now, what happens when Abiword is run is that the following code
gets executed during creation of a new document in
src/text/ptbl/xp/pd_Document.cpp:
PD_Document::PD_Document()
[...]
const gchar *name = g_get_real_name();
if(strcmp(name, Unknown) == 0)
name = g_get_user_name();
gchar *utf8name = g_locale_to_utf8(name, -1, NULL, NULL, NULL);
m_sUserName = utf8name;
g_free(utf8name);
The issue here is that as g_get_{real,user}_name() return the name in
ISO-8859-1 encoding, but the system locale is set to en_US.UTF-8, which
causes g_locale_to_utf8() conversion to fail and return NULL.
Which, in turn, causes a segfault in the m_sUserName = utf8name
assignation (you can't assign a NULL const char value to std::string).
While this may be considered an user error, I think it would be prudent to
not crash when such situation is encountered. Thus, I propose the
following patch:
--- src/text/ptbl/xp/pd_Document.cpp.orig 2012-10-26 17:51:28.0
+0300
+++ src/text/ptbl/xp/pd_Document.cpp2012-10-26 18:27:32.0 +0300
@@ -213,8 +213,13 @@
if(strcmp(name, Unknown) == 0)
name = g_get_user_name();
gchar *utf8name = g_locale_to_utf8(name, -1, NULL, NULL, NULL);
- m_sUserName = utf8name;
- g_free(utf8name);
+ if (utf8name != NULL)
+ {
+ m_sUserName = utf8name;
+ g_free(utf8name);
+ }
+ else
+ m_sUserName = Unknown;
}
PD_Document::~PD_Document()
Hope this helps.
--
] ccr/TNSP ^ pWp :: ccr tnsp org :: http://ccr.tnsp.org/
] PGP key: 0466 95ED 96DF 3701 C71D D62D 10A6 28A6 1374 C112--- src/text/ptbl/xp/pd_Document.cpp.orig 2012-10-26 17:51:28.0 +0300
+++ src/text/ptbl/xp/pd_Document.cpp 2012-10-26 18:27:32.0 +0300
@@ -213,8 +213,13 @@
if(strcmp(name, Unknown) == 0)
name = g_get_user_name();
gchar *utf8name = g_locale_to_utf8(name, -1, NULL, NULL, NULL);
- m_sUserName = utf8name;
- g_free(utf8name);
+ if (utf8name != NULL)
+ {
+ m_sUserName = utf8name;
+ g_free(utf8name);
+ }
+ else
+ m_sUserName = Unknown;
}
PD_Document::~PD_Document()
Bug#691301: abiword: Abiword segfaults, dumps core
On Wed, 24 Oct 2012, Dmitry Smirnov wrote: Hi Matti, Would you be able to reproduce with older kernel from testing please? Yep. Same result with vanilla / stock Debian testing kernel Linux mos6502 3.2.0-3-686-pae #1 SMP Mon Jul 23 03:50:34 UTC 2012 i686 GNU/Linux ii linux-image-3.2.0-3-686-pae 3.2.23-1 [...] (gdb) run Starting program: /usr/bin/abiword [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/i386-linux-gnu/i686/cmov/libthread_db.so.1. Program received signal SIGSEGV, Segmentation fault. __strlen_sse2_bsf () at ../sysdeps/i386/i686/multiarch/strlen-sse2-bsf.S:52 52 ../sysdeps/i386/i686/multiarch/strlen-sse2-bsf.S: No such file or directory. (gdb) bt #0 __strlen_sse2_bsf () at ../sysdeps/i386/i686/multiarch/strlen-sse2-bsf.S:52 #1 0xb7bca8e2 in PD_Document::PD_Document() () from /usr/lib/i386-linux-gnu/libabiword-2.9.so #2 0xb7cd3aba in AP_Frame::_loadDocument(char const*, int, bool) () from /usr/lib/i386-linux-gnu/libabiword-2.9.so #3 0xb7cd4895 in AP_Frame::loadDocument(char const*, int, bool) () from /usr/lib/i386-linux-gnu/libabiword-2.9.so #4 0xb7cd3017 in AP_Frame::loadDocument(char const*, int) () from /usr/lib/i386-linux-gnu/libabiword-2.9.so #5 0xb7c867d8 in AP_App::openCmdLineFiles(AP_Args const*) () from /usr/lib/i386-linux-gnu/libabiword-2.9.so #6 0xb7addfea in AP_UnixApp::main(char const*, int, char**) () from /usr/lib/i386-linux-gnu/libabiword-2.9.so #7 0x080484e3 in ?? () #8 0xb7790e46 in __libc_start_main (main=0x80484c0, argc=1, ubp_av=0xb884, init=0x80485e0, fini=0x80485d0, rtld_fini=0xb7ff0590, stack_end=0xb87c) at libc-start.c:228 #9 0x08048509 in ?? () (gdb) -- ] ccr/TNSP ^ pWp :: ccr tnsp org :: http://ccr.tnsp.org/ ] PGP key: 0466 95ED 96DF 3701 C71D D62D 10A6 28A6 1374 C112 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691301: abiword: Abiword segfaults, dumps core
On Wed, 24 Oct 2012, Dmitry Smirnov wrote: On Wed, 24 Oct 2012 12:57:02 Matti Hämäläinen wrote: Would you be able to reproduce with older kernel from testing please? Yep. Same result with vanilla / stock Debian testing kernel Thank you very much for trying that. Unfortunately I can't reproduce the issue neither I have any clues regarding what could be wrong. Could you please provide any information that you think might be helpful -- desktop environment, theme, strace output etc. No DE per se, just plain Window Maker, Adwaita Cupertino SL Gtk+ 2/3-theme (neither seem to be affecting this.) Anyway, I just noticed that there's a debug symbols package for Abiword .. oops - my bad. With the debug symbols, something interesting is revealed by GDB: Starting program: /usr/bin/abiword [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/i386-linux-gnu/i686/cmov/libthread_db.so.1. Program received signal SIGSEGV, Segmentation fault. __strlen_sse2_bsf () at ../sysdeps/i386/i686/multiarch/strlen-sse2-bsf.S:52 52 ../sysdeps/i386/i686/multiarch/strlen-sse2-bsf.S: No such file or directory. (gdb) bt #0 __strlen_sse2_bsf () at ../sysdeps/i386/i686/multiarch/strlen-sse2-bsf.S:52 #1 0xb7bca8e2 in length (__s=0x0) at /usr/include/c++/4.7/bits/char_traits.h:261 #2 assign (__s=0x0, this=0x856ddb4) at /usr/include/c++/4.7/bits/basic_string.h:1128 #3 operator= (__s=0x0, this=0x856ddb4) at /usr/include/c++/4.7/bits/basic_string.h:552 #4 PD_Document::PD_Document (this=0x856db80) at pd_Document.cpp:216 #5 0xb7cd3aba in AP_Frame::_loadDocument (this=this@entry=0x8150488, szFilename=szFilename@entry=0x0, ieft=ieft@entry=0, createNew=createNew@entry=false) at ap_Frame.cpp:202 #6 0xb7cd4895 in AP_Frame::loadDocument (this=0x8150488, szFilename=0x0, ieft=0, createNew=false) at ap_Frame.cpp:475 #7 0xb7cd3017 in AP_Frame::loadDocument (this=0x8150488, szFilename=0x0, ieft=0) at ap_Frame.cpp:513 #8 0xb7c867d8 in AP_App::openCmdLineFiles (this=0x804dc10, args=0xb6e8) at ap_App.cpp:70 #9 0xb7addfea in AP_UnixApp::main (szAppName=0x8048660 abiword, argc=1, argv=0xb874) at ap_UnixApp.cpp:1377 #10 0x080484e3 in main (argc=1, argv=0xb874) at ../src/wp/main/gtk/UnixMain.cpp:30 (gdb) The facts that szFilename is a NULL pointer and createNew is false seem wrong to me, but I can't bother to download the source tarball to see whether they actually have any relevance to this. Strace is over 500kB, so I'll refrain from attaching, but here's a link: http://tnsp.org/~ccr/abiword-strace.txt -- ] ccr/TNSP ^ pWp :: ccr tnsp org :: http://ccr.tnsp.org/ ] PGP key: 0466 95ED 96DF 3701 C71D D62D 10A6 28A6 1374 C112
Bug#589191: xmms: Failed to load libraries
Ummm... I'm not involved with Debian, but XMMS1 is dead, buried and was removed from Debian in 2008. In my opinion, this is not a Debian bug, as the package is not supported and isn't even in the Squeeze repositories. -- ] ccr/TNSP^DKD^pWp :: ccr tnsp org :: http://ccr.tnsp.org/ ] PGP key: 0466 95ED 96DF 3701 C71D D62D 10A6 28A6 1374 C112 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#588152: psmisc: 'pstree -a' without other arguments results in segfault
On Sun, 11 Jul 2010, Craig Small wrote: On Mon, Jul 05, 2010 at 06:32:42PM +0300, Matti H?m?l?inen wrote: Invoking 'pstree -a' without other arguments results in segmentation fault (at Hello, I've tested this on two different setups and both work fine. Are you able to run a strace on the program to show where it is faulting? If you're not sure how to do this, let me know and I'll give you instructions. pstree also needs access to /proc and someone suggested that perhaps grsec is interfering here. Are you able to temporarily disable it just to see if that is the general problem area? psmisc should work with a setup using grsec, failing gracefully if it has no access to something, but it would be nice to know if this is the cause. Finally, how are you running the program? On a text vty? gnome terminal? The environment may be triggering something. Indeed, it worked perfectly on stock Debian kernel, so basically my vanilla+grsec kernel was triggering it. I should have thought of that. However, after I fetched the source and did some debugging, I found the cause - namely certain struct elements are not initialized and as grsec prevents fetching information on later stage about PID 1 (as I have process hiding on) for non-root users .. thus the kaboom when accessing those struct members with garbage in them. Amusingly enough at first I suspected stack / heap trashing, because redirecting output of pstree made it work, but such was not the case. :P I am attaching a small patch that addresses this. -- ] ccr/TNSP^DKD^pWp :: ccr tnsp org :: http://ccr.tnsp.org/ ] PGP key: 0466 95ED 96DF 3701 C71D D62D 10A6 28A6 1374 C112diff -r 7471e48aefb0 src/pstree.c --- a/src/pstree.c Mon Jul 12 10:04:26 2010 +0300 +++ b/src/pstree.c Mon Jul 12 10:45:31 2010 +0300 @@ -268,6 +268,8 @@ new-pid = pid; new-uid = uid; new-flags = 0; +new-argc = 0; +new-argv = NULL; #ifdef WITH_SELINUX new-scontext = scontext; #endif/*WITH_SELINUX */
Bug#491615: audacious: 1.5.1-1 (Lenny) fails with a segmentation fault on startup
On Wed, 28 Oct 2009, A. Costa wrote: Thread 1 (Thread 0xb7137a40 (LWP 11836)): #0 0xb7da075a in ?? () from /lib/libglib-2.0.so.0 #1 0xb7da0faf in g_filename_from_uri () from /lib/libglib-2.0.so.0 #2 0xb7fb59f5 in vfs_file_test () from /usr/lib/libaudcore.so.1 #3 0xb655cbb7 in open_file () from /usr/lib/audacious/Input/timidity.so #4 0xb6564c08 in ?? () from /usr/lib/audacious/Input/timidity.so #5 0xb656559e in ?? () from /usr/lib/audacious/Input/timidity.so #6 0xb656559e in ?? () from /usr/lib/audacious/Input/timidity.so #7 0xb655c3bb in ?? () from /usr/lib/audacious/Input/timidity.so #8 0x0806427c in ?? () #9 0x0805b23a in ?? () #10 0xb74a8b36 in __libc_start_main () from /lib/i686/cmov/libc.so.6 #11 0x08055401 in ?? () (gdb) This backtrace points to the timidity plugin and a bug that I've already fixed in upstream (the fix will be in 2.2 release and is in the alphas/betas available now as source tarballs.) -- ] ccr/TNSP^DKD^pWp :: ccr tnsp org :: http://ccr.tnsp.org/ ] PGP key: 0466 95ED 96DF 3701 C71D D62D 10A6 28A6 1374 C112 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#476898: schism: Recommends should be changed to Suggests
Package: schism Version: 2:0+20080403-1 Severity: normal Currently schism package defines Recommends for various related packages, but according to Debian policy Suggests would be more appropriate for these. http://www.debian.org/doc/debian-policy/ch-relationships.html -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.24.4-grsec-axp Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages schism depends on: ii libc6 2.7-10 GNU C Library: Shared libraries ii libgcc1 1:4.2.2-4 GCC support library hi libsdl1.2debian 1.2.11-7 Simple DirectMedia Layer ii libstdc++64.2.2-4The GNU Standard C++ Library v3 ii libx11-6 2:1.0.3-7 X11 client-side library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii libxxf86misc1 1:1.0.1-2 X11 XFree86 miscellaneous extensio Versions of packages schism recommends: pn goattracker none (no description available) pn opencubicplayer none (no description available) pn xmms2-plugin-modplug none (no description available) pn xmp none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
