that's... weird. GTK would have been the most likely culprit but you say
it's the same version on both side
the fact that this is not isolated but a couple of people can reproduce is
also worrying. Unfortunately no devs seem to be hit by the problem
I am not suprised that importing a single image works, the crash seems
related to background jobs and these are not used when importing a single
image.
i'm not sure what else to tell you at that point...
On Tue, Aug 27, 2013 at 11:11 AM, Ivan Tarozzi <[email protected]> wrote:
> Thanks Jeremy,
> I give you some feedback in inline reply:
>
> Il 27/08/2013 09:34, jeremy rosen ha scritto:
> > Thanks for the report Ivan, this is indeed not the same crash
> >
> >
> > It is also a crash that happens in the background job handling (which
> > is why I was confused) but the locking seems to be correct.
> >
> > I don't see any really usefull info in that backtrace (other than the
> > fact that it crashes when destroying the background job in both cases)
> >
> > can any of you give me a little help on how to reproduce ? were you
> > importing a particularly large number of images ? a particularly deep
> > directory structure ? weird characters in the file names ?
>
> To avoid names related problem i created a directory :/home/ivan/testraw
> containig a single image renamed img.DNG .
> dt crash every time I import the folder. It doesn't crash when I import
> single image.
>
>
> > is it reproducible or random ?
>
> reproducible
>
> >
> > for people to able to read code, here is what I can tell from the
> > backtrace
> >
> > * all threads except the crashing threads are at rest
> > * the crashing thread crashed on the following line
> >
> > if(GTK_IS_WIDGET(j->widget)) <====== HERE
> > gtk_container_remove(GTK_CONTAINER(d->jobbox),j->widget);
> >
> >
> > apparently j is correct (i.e it's not null, I can't tell more from the
> > debug) so I believe the problem is that j->widget is not correct or NULL
> >
> > unfortunately I can't tell that from the BT and I can't do more than a
> > quick glance here. I didn't investigate the code to see who sets
> > j->widget or how it could be incorrect... Any help welcome
>
> I can confirm all what you wrote, but I can't understand why the SIGSEGV
> occours.
> I have another debian system where the same versione of dt works well
> (both 64bit).
> The 2 systems are not identical (installed packages, pinning,...) , and
> is not simple to compare all pkg versions. I checked gtk libs and seems
> to be the same.
>
> The non-working system is my notebook i5-4gb ram. I used git master on
> the same notebok in the last month without problems.
>
> Last test: i checked out an old commit
> (4b856e6ec99035d5a1041db73e2339000d395aa0) and it crash.
>
> I think the problem is related to a library I update in my system, but I
> can't remember when and what.
> I attach the result of dpkg -l \*
>
> Ivan
>
>
>
>
> Ivan
>
>
------------------------------------------------------------------------------
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
_______________________________________________
darktable-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/darktable-devel
