Bug#390388: inkscape: Destroys element's transformation when scale factor is small
Package: inkscape
Version: 0.44.1-1
Severity: normal
Consider following drawing (four squares 10 by 10 pixels):
--- test.svg ---
http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd'>
http://www.w3.org/2000/svg";
xmlns:xlink="http://www.w3.org/1999/xlink";>
--- eof ---
Inkscape draws it correctly, but if you try to move red, green or blue
square it will become BIG.
Open built-int XML editor and observe element attributes. Inkscape
add attributes "x", "y", "width" and "height", and modify value
of "transform" ('scale' & 'translate' become single 'matrix').
Problem: width has incorrect value, and transformation matrix
represents wrong translation (too small in this case). If you
continue moving such "deformed" element, scale factor disappear.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.4.27-2-686
Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2)
Versions of packages inkscape depends on:
ii libatk1.0-0 1.12.2-1The ATK accessibility toolkit
ii libbonobo2-0 2.14.0-1Bonobo CORBA interfaces library
ii libc62.3.6.ds1-4 GNU C Library: Shared libraries
ii libcairo21.2.4-1 The Cairo 2D vector graphics
libra
ii libdbus-1-3 0.93-1 simple interprocess messaging
syst
ii libfontconfig1 2.4.1-2 generic font configuration
library
ii libfreetype6 2.2.1-5 FreeType 2 font engine,
shared lib
ii libgc1c2 1:6.8-1 conservative garbage
collector for
ii libgcc1 1:4.1.1-14 GCC support library
ii libgconf2-4 2.14.0-4GNOME configuration database
syste
ii libglib2.0-0 2.12.3-2The GLib library of C routines
ii libglibmm-2.4-1c2a 2.12.0-1C++ wrapper for the GLib
toolkit (
ii libgnomevfs2-0 2.14.2-2+b1 GNOME virtual file-system
(runtime
ii libgtk2.0-0 2.8.20-2The GTK+ graphical user
interface
ii libgtkmm-2.4-1c2a1:2.8.8-1 C++ wrappers for GTK+ 2.4
(shared
ii liblcms1 1.15-1 Color management library
ii libloudmouth1-0 1.1.2-2 Lightweight C Jabber library
ii liborbit21:2.14.0-2 libraries for ORBit2 - a
CORBA ORB
ii libpango1.0-01.14.4-2Layout and rendering of
internatio
ii libpng12-0 1.2.8rel-5.2PNG library - runtime
ii libpopt0 1.10-3 lib for parsing cmdline
parameters
ii libsigc++-2.0-0c2a 2.0.17-2type-safe Signal Framework
for C++
ii libstdc++6 4.1.1-14The GNU Standard C++ Library v3
ii libx11-6 2:1.0.0-9 X11 client-side library
ii libxcursor1 1.1.7-4 X cursor management library
ii libxext6 1:1.0.1-2 X11 miscellaneous extension
librar
ii libxfixes3 1:4.0.1-4 X11 miscellaneous 'fixes'
extensio
ii libxft2 2.1.8.2-8 FreeType-based font drawing
librar
ii libxi6 1:1.0.1-3 X11 Input extension library
ii libxinerama1 6.8.2.dfsg.1-11 X Window System multi-head
display
ii libxml2 2.6.26.dfsg-3 GNOME XML library
ii libxrandr2 6.8.2.dfsg.1-9 X Window System Resize,
Rotate and
ii libxrender1 1:0.9.0.2-1 X Rendering Extension client
libra
ii libxslt1.1 1.1.17-4XSLT processing library -
runtime
ii zlib1g 1:1.2.3-13 compression library - runtime
Versions of packages inkscape recommends:
ii imagemagick 6:6.2.3.6-3 Image manipulation programs
pn libwmf-bin (no description available)
pn perlmagick (no description available)
ii pstoedit 3.41-1 PostScript and PDF files to
editab
-- no debconf information
Bug#392688: fontforge: svg.c -- missing quotes in SVG output
Subject: fontforge: svg.c -- missing quotes in SVG output Package: fontforge Version: 0.0.20060822-2 Severity: minor Just a few \" missing, I've attached patch. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.27-2-686 Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2) Versions of packages fontforge depends on: ii libc62.3.6.ds1-6 GNU C Library: Shared libraries ii libice6 1:1.0.1-2 X11 Inter-Client Exchange library ii libsm6 1:1.0.1-3 X11 Session Management library ii libx11-6 2:1.0.3-1 X11 client-side library Versions of packages fontforge recommends: ii libfreetype6 2.2.1-5 FreeType 2 font engine, shared lib ii libjpeg62 6b-13 The Independent JPEG Group's JPEG ii libpng12-0 1.2.8rel-5.2 PNG library - runtime ii libtiff4 3.8.2-6 Tag Image File Format (TIFF) libra ii libungif4g 4.1.4-4 shared library for GIF images pn libuninameslist0 (no description available) ii libxml22.6.26.dfsg-4 GNOME XML library ii zlib1g 1:1.2.3-13compression library - runtime -- no debconf information svg.c.patch Description: /
Bug#393487: SVG: outputs non-utf-8 characters
Package: fontforge Version: 0.0.20060822-2 Severity: normal FontForge fills with some informations, including user's full name. Program just copy it, so if the name contains national characters and encoding is not utf-8/latin1 (in system encoding is ISO-8859-2) XML parsers wont accept such ill formed SVG. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.27-2-686 Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2) Versions of packages fontforge depends on: ii libc62.3.6.ds1-6 GNU C Library: Shared libraries ii libice6 1:1.0.1-2 X11 Inter-Client Exchange library ii libsm6 1:1.0.1-3 X11 Session Management library ii libx11-6 2:1.0.3-2 X11 client-side library Versions of packages fontforge recommends: ii libfreetype6 2.2.1-5 FreeType 2 font engine, shared lib ii libjpeg62 6b-13 The Independent JPEG Group's JPEG ii libpng12-0 1.2.8rel-5.2 PNG library - runtime ii libtiff4 3.8.2-6 Tag Image File Format (TIFF) libra ii libungif4g 4.1.4-4 shared library for GIF images pn libuninameslist0 (no description available) ii libxml22.6.26.dfsg-4 GNOME XML library ii zlib1g 1:1.2.3-13compression library - runtime
Bug#427358: cdda2ogg (and cdda2mp3) failed to obtain full list of tracks
Package: icedax
Version: 1.1.6
The error is located in line 58:
LIST="$( $CDDA2WAV -J -vtoc -H 2>&1 | sed -e 's/^[^\ ].*//; s/\.([^)]*)/
/g;s/,//g;')"
One assumed that icedax returns list of tracks in format
"track_no.(time)". However I noticed that sometimes 'time'
part is surrounded with "||" or "[]"; here is sample:
569344 bytes buffer memory requested, 4 buffers, 55 sectors
Read TOC CD Text failed (probably not supported).
#icedax version 1.1.6, real time sched., soundcard, libparanoia support
1.( 5:57.15), 2.( 4:45.72), 3.( 5:05.05), 4.( 5:03.08), 5.(
5:25.05),
6.( 4:48.55), 7.( 0:20.70), 8.( 5:38.30), 9.( 5:29.45), 10.|
6:20.15|,
11.[ 9:20.57]
The simplest resolution is to replace "(", ")", "[", "]" to "|" and then
cut ".|time|":
sed -e 's/^[^\ ].*//; s/[][()]/|/g; s/\.|[^|]*|/ /g; s/,//g'
However I've found that icedax called with option -g (--gui)
prints data in grep-friendly format and also prints type of
track, i.e. audio, data, whatever, thus it makes possible to
rip JUST audio tracks. I've attached "my" version of cdda2ogg
that use icedax -g output.
w.
cdda2ogg
Description: Binary data
Bug#484784: gcc-4.3: -O2 -O3 - wrong arguments are passing to inlined body of function
Subject: gcc-4.3: -O2 -O3 - wrong arguments are passing to inlined body of
function
Package: gcc-4.3
Version: 4.3.0-5
Severity: important
Consider this simple program:
---bug.c---
#define N 100
char array[N];
void inline_asm(int iters) {
__asm__ volatile (
#ifdef PRESERVE_ALL_REGS
"pushal \n"
#endif
" xorl %%ebx, %%ebx \n"
"0: \n"
" movzbl (%%eax), %%edx \n"
" addl %%edx, %%ebx \n"
" incl %%eax \n"
" decl %%ecx \n"
" jnz 0b \n"
#ifdef PRESERVE_ALL_REGS
"popal \n"
#endif
: /* no output */
: "a" (array),
"c" (iters)
: "ebx", "edx"
);
}
int main() {
int n = 100;
while (n--)
inline_asm(N);
}
---eof---
Function inline_asm just add all values from array; all modified/input
registers are listed in __asm__ statement.
When program is compiled without any optimization flag, it works ok.
However if compiled with -O3 or -O3 --- segfaults. I quickly analyzed
assembly output, and it is clear, that gcc fully inlined procedure,
however in a while loop only address is restored (%eax), but inner loop
counter (%ecx) isn't. Thus in a second iteration %ecx has value 0, and
loop would execute 0x times, but segfault appear faster.
When sample program is compiled with -O3 -DPRESERVE_ALL_REGS all is
ok, because pair pushal/popal saves and restores all registers.
---bug.s---
main:
# .. snip ...
movl$array, %esi
pushl %ebx
pushl %ecx
movl$100, %ecx <-- ERROR: ecx is loaded only once
.p2align 4,,7
.p2align 3
#while
.L4:
movl%esi, %eax <-- OK: eax is reloaded in every while-iteration
#APP
# 6 "bug.c" 1
xorl %ebx, %ebx
0:
movzbl (%eax), %edx
addl %edx, %ebx
incl %eax
decl %ecx
jnz 0b
# 0 "" 2
#NO_APP
addl$1, %edi
cmpl$100, %edi
jne .L4
#endwhile
# ... snip ...
---cut---
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.25-2-686 (SMP w/2 CPU cores)
Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2)
Shell: /bin/sh linked to /bin/bash
Versions of packages gcc-4.3 depends on:
ii binutils2.18.1~cvs20080103-6 The GNU assembler, linker and bina
ii cpp-4.3 4.3.0-5 The GNU C preprocessor
ii gcc-4.3-base4.3.0-5 The GNU Compiler Collection (base
ii libc6 2.7-12 GNU C Library: Shared libraries
ii libgcc1 1:4.3.0-5GCC support library
ii libgomp14.3.0-5 GCC OpenMP (GOMP) support library
Versions of packages gcc-4.3 recommends:
ii libc6-dev 2.7-12 GNU C Library: Development Librari
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#911247: geeqie: Moving symlink to image crashes geeqie
Package: geeqie Version: 1:1.4+git20180925-1 Severity: important Dear Maintainer, How to reproduce: 1. Providing there's file.jpg, create symbolic link in the same directory ln -s file.jpg link.jpg 2. Open geeqie and navigate to link.jpg (geeqie displays image correctly). 3. Right click on the link.jpg, select "copy file" and copy the file to **another device**. 4. Geeqie crashes. When run from a console, it prints error messages, I noted two different: "corrupted double-linked list" and something about double free (sorry, lost the exact copy). In my case links are located on an external disc, and I'm trying to copy them to my home directory, which is mounted on a local hard drive. When I copy links within the same device, everything works! best regards Wojciech Muła -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), LANGUAGE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages geeqie depends on: ii geeqie-common1:1.4+git20180925-1 ii libatk1.0-0 2.26.1-3 ii libc62.27-2 ii libcairo21.15.8-3 ii libexiv2-14 0.25-3.1 ii libfontconfig1 2.12.6-0.1 ii libfreetype6 2.8.1-1 ii libgcc1 1:8-20180425-1 ii libgdk-pixbuf2.0-0 2.36.11-1 ii libglib2.0-0 2.54.3-2 ii libgtk2.0-0 2.24.32-1 ii libjpeg62-turbo 1:1.5.2-2+b1 ii liblcms2-2 2.9-1 ii liblirc-client0 0.10.0-2+b1 ii liblua5.1-0 5.1.5-8.1+b2 ii libpango-1.0-0 1.40.14-1 ii libpangocairo-1.0-0 1.40.14-1 ii libpangoft2-1.0-01.40.14-1 ii libstdc++6 8-20180425-1 ii libtiff5 4.0.9-3 ii sensible-utils 0.0.11 Versions of packages geeqie recommends: pn cups-bsd | lpr ii exiftran 2.10-2+b3 ii exiv20.25-3.1 ii imagemagick 8:6.9.7.4+dfsg-16 ii imagemagick-6.q16 [imagemagick] 8:6.9.7.4+dfsg-16 ii librsvg2-common 2.40.20-2 ii ufraw-batch 0.22-2 pn zenity Versions of packages geeqie suggests: pn geeqie-dbg ii gimp 2.8.20-1.1 ii libjpeg-turbo-progs [libjpeg-progs] 1:1.5.2-2+b1 pn ufraw pn xpaint -- no debconf information
Bug#911247: geeqie: Moving symlink to image crashes geeqie
Hi Andreas,
Thank you for the answer. This functionality is crucial for me, so I spent some
time
looking at this. The result is the attached patch (against sources obtained by
'apt-get source geeqie'). It works on my machine.
There were two problems:
1. Copying 'absolute' string onto memory of 'link_target';
'absolute' is most times longer than the length of 'link_target',
which is the cause of memory corruption and crashes.
2. Possible problem: using 'absolute' as a target for realpath. Function
realpath expects buffer of size PATH_MAX, and -- due to weird logic
in ifdefs I removed -- it might be too short. I think it's safer to
let realpath allocate sufficient memory and then just copy it.
best regards
Wojciech
W dniu 2018-10-17 21:27:25 użytkownik Andreas Ronnquist
napisał:
> On Wed, 17 Oct 2018 17:27:23 +0200 =?utf-8?q?Wojciech_Mu=C5=82a?=
> wrote:
> > How to reproduce:
> >
> > 1. Providing there's file.jpg, create symbolic link in the same
> > directory
> > ln -s file.jpg link.jpg
> >
> > 2. Open geeqie and navigate to link.jpg (geeqie displays image
> > correctly). 3. Right click on the link.jpg, select "copy file" and
> > copy the file to **another device**.
> > 4. Geeqie crashes. When run from a console, it prints error messages,
> >I noted two different: "corrupted double-linked list" and something
> >about double free (sorry, lost the exact copy).
> >
> > In my case links are located on an external disc, and I'm trying to
> > copy them to my home directory, which is mounted on a local hard
> > drive. When I copy links within the same device, everything works!
> >
> >
>
> Thanks for your report! This has been fixed in the git repo upstream,
> and I will include this soon in a fix in Debian too. (I will
> most probably package a new git snapshot).
>
> However, please notice that upstream has solved the problem by reverting
> other fixes to make copying symlinks to images in geeqie also symlink
> at the copy target, and instead dereferencing the symlink target. This
> means that the result target when copying a symlink to an image will be
> a copy of the image the symlink targets, and not a new symlink with the
> same target as the source.
>
> (Upstream bug report at:
> https://github.com/BestImageViewer/geeqie/issues/640 )
>
> best
> /Andreas
> gus...@debian.org
> andr...@ronnquist.net
>
--- src/ui_fileops.c.orig 2018-10-18 15:04:33.166775353 +0200
+++ src/ui_fileops.c 2018-10-18 15:20:05.648723223 +0200
@@ -573,33 +573,24 @@
char *lastslash = strrchr(sl, G_DIR_SEPARATOR);
int len = lastslash - sl + 1;
- int path_max;
-#ifdef PATH_MAX
- path_max = PATH_MAX;
-#else
- path_max = pathconf(sl, _PC_PATH_MAX);
- if (path_max <= 0)
-path_max = 4096;
-#endif
-
- absolute = g_malloc(path_max + 1);
-
+ absolute = g_malloc(len + st.st_size + 1);
strncpy(absolute, sl, len);
strcpy(absolute + len, link_target);
- strcpy(link_target, absolute);
+g_free(link_target);
+link_target = absolute;
char *realPath;
- realPath = realpath(link_target, absolute);
+ realPath = realpath(link_target, NULL);
if (realPath != NULL) // successfully resolved into an absolute path
{
g_free(link_target);
-link_target = absolute;
+link_target = g_strdup(realPath);
+free(realPath);
}
else // could not get absolute path, got some error instead
{
g_free(link_target);
-g_free(absolute);
goto orig_copy; // so try a "normal" copy
}
}
Bug#961376: rawtherapee: Segmentation fault at program termination
Package: rawtherapee Version: 5.8-1 Severity: normal When rawtherapee is run from command line to edit a single file, like: $ rawtherapee DSC_4572.NEF it sometimes segfaults after closing the main window. A .pp3 file seems to be written without any errors. Here are two gdb sessions I captured. The source of SIGSEGV is located in the main window's destructor, looks to me like uninitialized member or double free. Backtrace #1: Thread 1 "rawtherapee" received signal SIGSEGV, Segmentation fault. 0x55abacbb in RTWindow::~RTWindow (this=0x562c7cb0, __in_chrg=, __vtt_parm=) at ./rtgui/rtwindow.cc:467 467 ./rtgui/rtwindow.cc: No such file or directory. (gdb) bt #0 0x55abacbb in RTWindow::~RTWindow (this=0x562c7cb0, __in_chrg=, __vtt_parm=) at ./rtgui/rtwindow.cc:467 #1 0x55abad99 in RTWindow::~RTWindow (this=0x562c7cb0, __in_chrg=, __vtt_parm=) at ./rtgui/rtwindow.cc:455 #2 0x557d2782 in std::default_delete::operator() (this=, __ptr=0x562c7cb0) at /usr/include/c++/9/bits/unique_ptr.h:75 #3 std::unique_ptr >::~unique_ptr (this=, __in_chrg=) at /usr/include/c++/9/bits/unique_ptr.h:284 #4 main (argc=, argv=) at ./rtgui/main.cc:564 Backtrace #2: Thread 1 "rawtherapee" received signal SIGSEGV, Segmentation fault. 0x55abacd0 in RTWindow::~RTWindow (this=0x568a7280, __in_chrg=, __vtt_parm=) at ./rtgui/rtwindow.cc:468 468 ./rtgui/rtwindow.cc: No such file or directory. (gdb) bt #0 0x55abacd0 in RTWindow::~RTWindow (this=0x568a7280, __in_chrg=, __vtt_parm=) at ./rtgui/rtwindow.cc:468 #1 0x55abad99 in RTWindow::~RTWindow (this=0x568a7280, __in_chrg=, __vtt_parm=) at ./rtgui/rtwindow.cc:455 #2 0x557d2782 in std::default_delete::operator() (this=, __ptr=0x568a7280) at /usr/include/c++/9/bits/unique_ptr.h:75 #3 std::unique_ptr >::~unique_ptr (this=, __in_chrg=) at /usr/include/c++/9/bits/unique_ptr.h:284 #4 main (argc=, argv=) at ./rtgui/main.cc:564 -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages rawtherapee depends on: ii libatkmm-1.6-1v52.28.0-2 ii libc6 2.30-4 ii libcairomm-1.0-1v5 1.12.2-4 ii libcanberra-gtk3-0 0.30-7 ii libcanberra00.30-7 ii libexpat1 2.2.9-1 ii libfftw3-single33.3.8-2 ii libgcc-s1 10-20200321-1 ii libglib2.0-02.64.1-1 ii libglibmm-2.4-1v5 2.62.0-1 ii libgomp110-20200321-1 ii libgtk-3-0 3.24.14-1 ii libgtkmm-3.0-1v53.24.2-1 ii libiptcdata01.0.5-2.1 ii libjpeg62-turbo 1:1.5.2-2+b1 ii liblcms2-2 2.9-4+b1 ii liblensfun1 0.3.2-5 ii libpangomm-1.4-1v5 2.42.0-2 ii libpng16-16 1.6.37-2 ii librsvg2-2 2.46.4-1 ii libsigc++-2.0-0v5 2.10.2-1 ii libstdc++6 10-20200321-1 ii libtiff54.1.0+git191117-2 ii rawtherapee-data5.8-1 ii zlib1g 1:1.2.11.dfsg-2 rawtherapee recommends no packages. rawtherapee suggests no packages. -- no debconf information
Bug#980859: sylpheed: Hang when displaying specific message
Package: sylpheed Version: 3.7.0-8 Severity: important X-Debbugs-Cc: wojciech_m...@poczta.onet.pl Dear Maintainer, * What led up to the situation? Tried to read a typical Github notification email. * What exactly did you do (or not do) that was effective (or ineffective)? Clicked on the unread message in the message list window. * What was the outcome of this action? Sylpheed became unreportable at all, CPU usage was 100%. I had to kill the program manually from a command line. * What outcome did you expect instead? Just displaying a mail. The message which caused this strange behaviour is a regular Github notification. What I did before reporting the bug: 1. I found that message in the mail folder and tried to distill the minimal example by removing headers or body lines, but didn't found any obvious pattern. 2. I compiled Sylpheed from Debian sources and then run inside gdb. Seems it's some bug inside GTK, like endless loop of signals. I can break the program (Ctrl-C), inspect the backtrace and continue, and then break again. Please see the sample backtrace below: the last function from Sylpheed is `summary_select_row`, then only GTK functions are being called. What I observed is that rarely the mail is displayed on the screen, and then program stops responding. Usually there's blank message window. I have a custom GTK theme set via `export GTK_THEME=Blackbird`. Please drop me a line and I'll share with the maintainer & developers the problematic message. It contains mails, logins, names, etc., don't want to publish them in the bug report. best regards Wojciech Muła Thread 1 "sylpheed" received signal SIGINT, Interrupt. 0x7791e6e4 in pango_script_iter_next () from /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0 (gdb) bt #0 0x7791e6e4 in pango_script_iter_next () at /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0 #1 0x7791e8b6 in () at /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0 #2 0x77909994 in () at /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0 #3 0x7790b124 in pango_itemize_with_base_dir () at /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0 #4 0x77914366 in () at /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0 #5 0x77916249 in () at /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0 #6 0x77d3d858 in gtk_text_layout_get_line_display () at /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #7 0x77d3e4e2 in () at /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #8 0x77d22e03 in () at /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #9 0x77d3ce48 in gtk_text_layout_validate_yrange () at /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #10 0x77d4d5bb in () at /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #11 0x77d4e61c in () at /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #12 0x77d4ec31 in () at /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #13 0x778a3fc4 in g_closure_invoke () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #14 0x778b609a in () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #15 0x778bc69f in g_signal_emit_valist () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #16 0x778bcc0f in g_signal_emit () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #17 0x77db3163 in gtk_widget_size_allocate () at /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #18 0x77cf2d7a in () at /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #19 0x778a3fc4 in g_closure_invoke () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #20 0x778b609a in () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #21 0x778bc69f in g_signal_emit_valist () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #22 0x778bcc0f in g_signal_emit () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #23 0x77db3163 in gtk_widget_size_allocate () at /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #24 0x77bdb6e4 in () at /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #25 0x778a3fc4 in g_closure_invoke () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #26 0x778b609a in () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #27 0x778bc69f in g_signal_emit_valist () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 --Type for more, q to quit, c to continue without paging-- #28 0x778bcc0f in g_signal_emit () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #29 0x77db3163 in gtk_widget_size_allocate () at /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #30 0x77cb133d in () at /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #31 0x778a3fc4 in g_closure_invoke () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #32 0x778b609a in () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #33 0x778bc69f in g_signal_emit_valist () at /usr/lib/x
Bug#948293: geeqie: Geeqie crashes when name of new dir is the same as the existing file
Package: geeqie Version: 1:1.5.1-5 Severity: normal Steps to reproduce: Create a file: $ touch 1 Then run geeqie in the same directory, like $ geeqie Finally click right on the directory listing, select the option "New directory..." and enter the name of the just created file, i.e. "1". On accepting, geeqie terminates. When run in gdb, following error is shown: ERROR:filedata.c:654:file_data_new_dir: assertion failed: (S_ISDIR(st.st_mode)) -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), LANGUAGE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages geeqie depends on: ii geeqie-common1:1.5.1-5 ii libc62.29-2 ii libcairo21.16.0-4 ii libexiv2-14 0.25-4 ii libffmpegthumbnailer4v5 2.1.1-0.2+b1 ii libgcc1 1:9.2.1-19 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-0 2.58.3-2 ii libgtk2.0-0 2.24.32-3 ii libjpeg62-turbo 1:1.5.2-2+b1 ii liblcms2-2 2.9-3 ii liblirc-client0 0.10.1-5.2 ii liblua5.1-0 5.1.5-8.1+b2 ii libpango-1.0-0 1.42.4-6 ii libpangocairo-1.0-0 1.42.4-6 ii libstdc++6 9.2.1-19 ii libtiff5 4.0.10-4 ii sensible-utils 0.0.12 Versions of packages geeqie recommends: pn cups-bsd | lpr pn exiftran ii exiv20.25-4 ii imagemagick 8:6.9.10.23+dfsg-2.1 ii imagemagick-6.q16 [imagemagick] 8:6.9.10.23+dfsg-2.1 ii librsvg2-common 2.44.10-2.1 ii ufraw-batch 0.22-4 pn zenity Versions of packages geeqie suggests: pn geeqie-dbg ii gimp 2.10.8-2 ii libjpeg-turbo-progs [libjpeg-progs] 1:1.5.2-2+b1 pn ufraw pn xpaint -- debconf-show failed
Bug#915299: xfburn: Segfault when adding files to project
Package: xfburn Version: 0.5.5-1 Severity: important Dear Maintainer, To reproduce bug: 1. Open xfburn, select "New data composition" 2. Add a file by clicking "Add" button. Now select file in the dialog box and press Enter -- there's segfault. When selected file is added by clicking "Add" button (that one on the dialog box), everything works. gdb output: Thread 1 "xfburn" received signal SIGSEGV, Segmentation fault. 0x75ddb54b in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (gdb) bt #0 0x75ddb54b in g_signal_emit_valist () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 best regards Wojciech -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), LANGUAGE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xfburn depends on: ii libburn41.4.8-1 ii libc6 2.27-2 ii libexo-1-0 0.10.7-1 ii libgdk-pixbuf2.0-0 2.38.0+dfsg-6 ii libglib2.0-02.58.1-2 ii libgstreamer-plugins-base1.0-0 1.14.0-2 ii libgstreamer1.0-0 1.14.0-1 ii libgtk2.0-0 2.24.32-1 ii libgudev-1.0-0 232-1 ii libisofs6 1.4.8-1 ii libxfce4ui-1-0 4.12.1-3 ii libxfce4util7 4.12.1-3 xfburn recommends no packages. xfburn suggests no packages. -- no debconf information
Bug#915299: Bug #915299: xfburn: Segfault when adding files to project
Hi Bernhard! Thank you very much for looking at this issue. The outdated versions of libs are the most likely cause of segfault, so I propose to close the bug. I'll back to this when I do whole-system upgrade. BTW, the gdb backtrace I posted are the only lines printed by gdb. :) best regards Wojciech W dniu 2018-12-05 11:27:05 użytkownik Bernhard Übelacker napisał: > Hello Wojciech Muła, > I am just trying to reproduce the crash inside a minimal > buster amd64 qemu VM. > > Unfortunately I was not able to reproduce and found most of > the listed versions are already outdated in testing. > > Is there a reason, why your debian unstable installation > is not receiving updates? > > Another point would be, you copied just the first frame of > gdb's bt output, but there should have been more lines following? > > And such a backtrace would be even better if the matching dbgsym > packages are installed like described in [1]. In your example that > would be at least xfburn-dbgsym libglib2.0-0-dbgsym. > (But I guess if you currently do not install updates on purpose > that would pull in new versions of the libraries.) > > Kind regards, > Bernhard > > > [1] https://wiki.debian.org/HowToGetABacktrace > > > # dpkg -S /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > libglib2.0-0:amd64: /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 >
