On Fri, 2015-07-10 at 08:27 +1000, James C. McPherson wrote:
> On 10/07/15 06:23 AM, Tobias Ellinghaus wrote:
> > Am Donnerstag, 9. Juli 2015, 13:06:21 schrieb David Vincent-Jones:
> >
> > [...]
> >
> >> The debug information is attached.
> >
> > That is not a backtrace. Please have a look in /tmp/, darktable might have
> > written one there.
>
> You're right, it isn't.
>
> Still, what we have here is looking like smoke:
>
>
> david@linux:~> darktable
> *** buffer overflow detected ***: darktable terminated
> ======= Backtrace: =========
> /lib64/libc.so.6(+0x7283f)[0x7f2b5ac0d83f]
> /lib64/libc.so.6(__fortify_fail+0x37)[0x7f2b5ac904f7]
> /lib64/libc.so.6(+0xf3710)[0x7f2b5ac8e710]
> /lib64/libc.so.6(+0xf2c19)[0x7f2b5ac8dc19]
> /lib64/libc.so.6(_IO_default_xsputn+0x89)[0x7f2b5ac108e9]
> /lib64/libc.so.6(_IO_vfprintf+0xacf)[0x7f2b5abe1d5f]
> /lib64/libc.so.6(__vsprintf_chk+0x88)[0x7f2b5ac8dca8]
> /lib64/libc.so.6(__sprintf_chk+0x7d)[0x7f2b5ac8dbfd]
> /usr/lib64/darktable/plugins/lighttable/libprint_settings.so(+0x3c03)[0x7f2affd13c03]
> /usr/lib64/libgobject-2.0.so.0(+0x110a7)[0x7f2b58cb20a7]
> /usr/lib64/libgobject-2.0.so.0(g_signal_emit_valist+0x438)[0x7f2b58cca3d8]
> /usr/lib64/libgobject-2.0.so.0(g_signal_emit_by_name+0x522)[0x7f2b58ccb552]
> /usr/lib64/darktable/plugins/lighttable/libprint_settings.so(+0x58ad)[0x7f2affd158ad]
> /usr/lib64/libgobject-2.0.so.0(+0x110a7)[0x7f2b58cb20a7]
> /usr/lib64/libgobject-2.0.so.0(g_signal_emit_valist+0x438)[0x7f2b58cca3d8]
> /usr/lib64/libgobject-2.0.so.0(g_signal_emit_by_name+0x522)[0x7f2b58ccb552]
> /usr/lib64/darktable/plugins/lighttable/libprint_settings.so(+0x5dc0)[0x7f2affd15dc0]
> /usr/bin/../lib64/darktable/libdarktable.so(+0x19ed13)[0x7f2b5b2fdd13]
> /usr/bin/../lib64/darktable/libdarktable.so(+0xdd35f)[0x7f2b5b23c35f]
> /lib64/libpthread.so.0(+0x80a4)[0x7f2b5af4a0a4]
> /lib64/libc.so.6(clone+0x6d)[0x7f2b5ac8008d]
>
> ... and where's there's smoke etc.
>
> In git master, src/libs/print_settings.c has 3 occurrences of sprintf():
>
>
>
> static void
> _update_slider (dt_lib_print_settings_t *ps)
> {
> ...
>
> sprintf(value, "%3.2f", w);
> gtk_label_set_text(GTK_LABEL(ps->width), value);
> sprintf(value, "%3.2f", h);
> gtk_label_set_text(GTK_LABEL(ps->height), value);
> // compute the image down/up scale and report information
> double scale;
> if (iwidth >= awidth)
> scale = dt_pdf_point_to_pixel(dt_pdf_mm_to_point((double)awidth),
> ps->prt.printer.resolution) / ps->iwidth;
> else
> scale = dt_pdf_point_to_pixel(dt_pdf_mm_to_point((double)aheight),
> ps->prt.printer.resolution) / ps->iheight;
>
> sprintf(value, _("%3.2f (dpi:%d)"), scale, scale<=1.0 ?
> (int)ps->prt.printer.resolution : (int)(ps->prt.printer.resolution / scale));
> gtk_label_set_text(GTK_LABEL(ps->info), value);
> }
>
>
> Of these, it appears to me that the last (line 520) is the most likely
> to have been where the crash occurred.
>
> xxx.xx (dpi:xxxx)
>
> is 18 chars, and then it's pushed through gettext().
>
> Recommendation #1 - increase the size of value[]
> Recommendation #2 - use snprintf() instead of sprintf()
> Recommendation #3 - don't push that final string through gettext().
>
>
>
> James C. McPherson
I am finding that dt starts when run through gdb. ... so far it starts
every time this way.
David
------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
darktable-devel mailing list
darktable-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/darktable-devel
