Follow-up to comments on chat addressed to pmjdebruijn
Opened an image in print module.
Changed paper size
Started changing borders using +/- (inch units)
As I had a large change to make I tried to type in a new border width.
dt closed.
When I opened dt again the image appeared to have been remo
I imported a number of jpg files and then tried to move the entire set into an
existing image folder. dt then closed. I can now open dt but it either closes
within a few seconds or simply freezes. From the terminal it looks like this:
warning: /etc/gdbinit.d/gdb-heap.py: No such file or director
I have an image with two instances of shadows & highlights.
This leads to a crash which is 100% reproducible (OS X, 1.6.0):
1. Deleting one module instance
2. Resetting the leftover one
Or:
1. Resetting one module instance
2. Deleting the leftover one
Crashed Thread:4
Exception Type:
Jeremy,
> Thx for finding it, I fixed that locally (will push soon)
> This is due to the new parameter versionning system that was
> implemented for storages but lua was not adapted for it.
Working fine on my side now. Thanks a lot for the quick fix Jeremy!
--
Pascal Obry / Magny Les Hamea
Thx for finding it, I fixed that locally (will push soon)
This is due to the new parameter versionning system that was implemented
for storages but lua was not adapted for it.
On Thu, Sep 25, 2014 at 7:51 PM, Pascal Obry wrote:
>
> We probably want to fix that before the release.
>
> Put the fo
We probably want to fix that before the release.
Put the following Lua script into your local Lua directory.
Start dt and do:
- select "Gimp" in the export dialog target storage
- select the preset button to create a new preset
- dt crashes
The backtrace is:
> Program received signal SIGSEGV,
Can you share the mask (i.e. XMP) please?
Ulrich
Am 02.05.2014 23:39, schrieb Moritz Moeller:
> I was editing a single mask (path) for almost an hour before this
> happened. So mask stability has improved heaps.
> Also, after the crash, only the very last edit on the mask was missing.
> Great wor
I was editing a single mask (path) for almost an hour before this
happened. So mask stability has improved heaps.
Also, after the crash, only the very last edit on the mask was missing.
Great work!
The call stack is not very indicative (I was not running a debug build).
Process: darktabl
Hello.
If this is reproducible for you, you should try to `git bisect` commit that
causing this.
On Tue, Apr 8, 2014 at 4:09 PM, Moritz Moeller wrote:
> Latest master builds fine now but doesn't start any more:
>
> Process: darktable [53820]
> Path:/opt/darktable/*/darktable
Latest master builds fine now but doesn't start any more:
Process: darktable [53820]
Path:/opt/darktable/*/darktable
Identifier: darktable
Version: 0
Code Type: X86-64 (Native)
Parent Process: zsh [348]
Responsible: iTerm [244]
User ID: 508
Date
On Wed, 8 Jan 2014 20:10:28 +0400
parafin wrote:
> On Fri, 27 Dec 2013 18:27:45 +0100
> Moritz Moeller wrote:
>
> > > I don't have observed issues here. I can change the zoom level and the
> > > center view immediately gets updated. Same if I pan the small rectangle
> > > to change the region o
On Fri, 27 Dec 2013 18:27:45 +0100
Moritz Moeller wrote:
> > I don't have observed issues here. I can change the zoom level and the
> > center view immediately gets updated. Same if I pan the small rectangle
> > to change the region of interest.
>
> Yes, the ROI update is instant on OS X too. Bu
2014/1/3 Ulrich Pegelow :
> Am 03.01.2014 09:46, schrieb Frederic Crozat:
>> Hi all,
>>
>> I'm able to easily trigger a crash when adding / removing mask in spot
>> removal module.
>>
>> Feel free to ask for more informations, if needed.
>>
>
> Yes, I ask you :) Would you be so kind to releal more
Am 03.01.2014 09:46, schrieb Frederic Crozat:
> Hi all,
>
> I'm able to easily trigger a crash when adding / removing mask in spot
> removal module.
>
> Feel free to ask for more informations, if needed.
>
Yes, I ask you :) Would you be so kind to releal more of your findings,
e.g. what to do in
Hi all,
I'm able to easily trigger a crash when adding / removing mask in spot
removal module.
Feel free to ask for more informations, if needed.
Here is a trace of the crash:
Program received signal SIGSEGV, Segmentation fault.
dt_masks_gui_form_remove (form=form@entry=0x1e5bbb0, gui=gui@entry
Actually, got another one. This time I had ran an export task
immediately before quitting (the task had finished though):
Crashed Thread: 4
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: EXC_I386_GPFLT
Application Specific Information:
Performing @selector(terminate:) from sender N
Got this thrice already, today:
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x, 0x
Application Specific Information:
abort() called
*** error for object 0x135002ec0: pointer being freed was not a
I have not complained earlier but I have had a number of mask problems
which I feel now may have resulted from using reentrants that caused an
overlap of the fade boundary.
David
On 27/12/13 06:32 AM, Ulrich Pegelow wrote:
Can you offer a recipe of how to reproduce the crash? From the backtrac
On 27/12/13 6:20 pm, Ulrich Pegelow wrote:
> No, these are totally independent.
That would be very nice though. This is a common workflow for roto:
start with base shape, then add CVs to match the actual shape better.
For this, it would be so nice if DT finally had context menus (i.e. RMB
on a pa
Am 27.12.2013 18:12, schrieb Moritz Moeller:
> On 27/12/13 6:04 pm, Ulrich Pegelow wrote:
>> Guess I found the cause. Too bad this got only discovered just after the
>> release :/
>
> Well, I think it's not such an issue to do 1.4.1, innit? :D
>
> Btw, is there a way to convert an ellipse path into
On 27/12/13 6:04 pm, Ulrich Pegelow wrote:
> Guess I found the cause. Too bad this got only discovered just after the
> release :/
Well, I think it's not such an issue to do 1.4.1, innit? :D
Btw, is there a way to convert an ellipse path into one consisting of
editable CVs?
Also, there still is
Am 27.12.2013 17:56, schrieb Moritz Moeller:
> On 27/12/13 5:52 pm, Ulrich Pegelow wrote:
>> Some info on the size of the image (w * h) and the rough percentage of
>> area covered by the path would be fine.
>
> The images come from my GH2, so they're RAWs 4752x3168 in size.
>
> I'd say the path I w
On 27/12/13 5:52 pm, Ulrich Pegelow wrote:
> Some info on the size of the image (w * h) and the rough percentage of
> area covered by the path would be fine.
The images come from my GH2, so they're RAWs 4752x3168 in size.
I'd say the path I was trying to edit covered less that 10% of the
image's
Am 27.12.2013 17:35, schrieb Moritz Moeller:
> On 27/12/13 3:32 pm, Ulrich Pegelow wrote:
>> Can you offer a recipe of how to reproduce the crash? From the backtrace
>> I would guess that this happens if the path has a significant portion of
>> self-intersections.
>
> This path had max. 1 self inte
On 27/12/13 3:32 pm, Ulrich Pegelow wrote:
> Can you offer a recipe of how to reproduce the crash? From the backtrace
> I would guess that this happens if the path has a significant portion of
> self-intersections.
This path had max. 1 self intersections (and 4 CVs, I believe to
recall). So far
Can you offer a recipe of how to reproduce the crash? From the backtrace
I would guess that this happens if the path has a significant portion of
self-intersections.
Ulrich
Am 25.12.2013 20:43, schrieb Moritz Moeller:
> I get this crash regularly, when editing path-based masks in 1.4 on OS X
>
Another one. Basically, editing path-based masks on DT 1.4 on OS X is
close to impossible atm, its simply too unstable:
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x000134825000
VM Regions Near
On 25/12/13 8:43 pm, Moritz Moeller wrote:
> I get this crash regularly, when editing path-based masks in 1.4 on OS X
> 10.9.1:
>
> Thread 7 Crashed:
> 0 libsystem_kernel.dylib0x7fff8a3f9866 __pthread_kill + 10
> 1 libsystem_pthread.dylib 0x7fff890c235c pthread_ki
I get this crash regularly, when editing path-based masks in 1.4 on OS X
10.9.1:
Thread 7 Crashed:
0 libsystem_kernel.dylib 0x7fff8a3f9866 __pthread_kill + 10
1 libsystem_pthread.dylib 0x7fff890c235c pthread_kill + 92
2 libsystem_c.dylib 0x0
http://chromasoft.blogspot.de/2012/05/demosaicing-fuji-x-pro1-and-its-x-trans.html
is a good read about the special needs sensor. i especially liked the
conclusion:
`*Firstly, Fuji X-Pro1 images are a pig to interpolate*, and don't appear
to show better resolution than a conventional sensor, even
hi,
it's a real sad fact, that you don't support fuji raws with the x-trans
non bayer sensor!
But I really like darktable , and I also still use my canon 40D one in a
while , which is not a challenge for darktable at all,but..
if I want to use dt to manage all my pictures, it always crashes - when
Le 31/07/2013 16:44, Wolfgang Beutner a écrit :
> Considering my system: 16Gb of memory, and as you probably guessed from
> the memory map, running on 64 bit's. No opencl activated and just the
> two filters that are automatically involved when importing a raw,
> sharpen and basecurve. I know mallo
Ok, I downgraded to the previous version darktable 1.3_696_gbdb2604
which is the right one for the supplied debug files.
I scrolled through some images in the filmroll, switched to darkroom and
zoomed in and out which produced the crash and here is the backtrace:
(gdb) bt
#0 0x773be3d5
Hi,
I tried to get the needed information, but seems to be difficult. The
repository I'm using is
http://download.opensuse.org/repositories/home:/toganm:/photography/openSUSE_12.3/.
Seems to be lacking the right debuginfo package. I installed it but get
a message when starting with gdb that t
Well found some other strange things that were probably caused by the
database being kind of messed up. Maybe this was the reason for my
problems. Investigated the database and came to the conclusion a fresh
start would be better. So I removed the DB and for the moment that seems
to be ok, sorr
can't reproduce. do you have a stack trace? or the particular image? maybe
it's corrupted? or is there a pre-existing xmp with any special settings in
it?
j.
On Mon, Jul 29, 2013 at 3:50 AM, Wolfgang Beutner
wrote:
> Seems I have found a repeatable crash when trying to load a single raw
>
Seems I have found a repeatable crash when trying to load a single raw
image from a folder. The folder is a nfs-mount on my local server. When
I select a single image and start the import the program crashes with a
memfault.
Seems to be somehow related to GTK:(darktable:792
On Tue, Jul 16, 2013 at 5:32 PM, Bruce Guenter wrote:
> On Sat, Jul 13, 2013 at 08:43:32PM +1200, johannes hanika wrote:
> > maybe we pass a non 4-float boundary aligned buffer?
>
> That seems unlikely. Wouldn't that cause problems on other CPUs too?
>
true, that should immediately crash on all
On Sat, Jul 13, 2013 at 08:43:32PM +1200, johannes hanika wrote:
> maybe we pass a non 4-float boundary aligned buffer?
That seems unlikely. Wouldn't that cause problems on other CPUs too?
--
Bruce Guenter http://untroubled.org/
signature.asc
Description: Digital signature
maybe we pass a non 4-float boundary aligned buffer?
j.
On Sat, Jul 13, 2013 at 11:48 AM, Bruce Guenter wrote:
> On Wed, Jul 10, 2013 at 08:51:28PM -0600, Bruce Guenter wrote:
> > So I'm thinking this is something hardware related. I plugged the hard
> > drive into my desktop and booted it into
On Wed, Jul 10, 2013 at 08:51:28PM -0600, Bruce Guenter wrote:
> So I'm thinking this is something hardware related. I plugged the hard
> drive into my desktop and booted it into a virtual machine, and I've run
> the exports dozens of times and it has yet to crash. I stuck it back
> into the laptop
On Thu, Jul 11, 2013 at 01:11:54PM +1000, James C. McPherson wrote:
> Is this a usb-attached hard disk? The adherence to Standards
> with many of them is, shall we say, lacking.
No, it isn't. It is the internal drive in the laptop, but I pulled it
out of the laptop and put it into an enclosure for
On 07/11/13 12:51 PM, Bruce Guenter wrote:
...
> So I'm thinking this is something hardware related. I plugged the hard
> drive into my desktop and booted it into a virtual machine, and I've run
> the exports dozens of times and it has yet to crash. I stuck it back
> into the laptop to verify and y
On Wed, Jul 10, 2013 at 01:15:59PM -0600, Bruce Guenter wrote:
> I thought I had it
> completely working with the default, actually, but it just crashed both
> ways so I'm back to square one.
So I'm thinking this is something hardware related. I plugged the hard
drive into my desktop and booted i
On Tue, Jul 09, 2013 at 09:21:21AM +0200, johannes hanika wrote:
> right. so i have turbo after all. that's strange.
For whatever reason, it seems to crash much more often with --buildtype
RelWithDebInfo than with the default of Release. I thought I had it
completely working with the default, actu
right. so i have turbo after all. that's strange.
dpkg -l libjpeg*
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name
Version Architecture
On Mon, Jul 08, 2013 at 04:31:10PM +0200, johannes hanika wrote:
> hm. i seem to have libjpeg8 without turbo.
>
> $ dpkg -l libjpeg8*
> Desired=Unknown/Install/Remove/Purge/Hold
> |
> Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> |/ Err?=(none)/Reinst-required (Sta
hm. i seem to have libjpeg8 without turbo.
$ apt-cache depends libtiff5
libtiff5
Depends: libc6
Depends: libjbig0
Depends: libjpeg8
Depends: liblzma5
Depends: zlib1g
PreDepends: multiarch-support
multiarch-support:i386
Replaces: libtiff5:i386
Breaks: libtiff5:i386
$ dpkg -l
On Mon, Jul 08, 2013 at 03:09:30PM +0200, johannes hanika wrote:
> ah, i missed that piece of information. no, i'm using vanilla jpeg here.
Over this weekend, I was trying to remove the libjpeg-turbo installation
in order to use just the vanilla libjpeg. I'll gladly give up the speed
boost it give
ah, i missed that piece of information. no, i'm using vanilla jpeg here.
quite possible that we use the library slightly wrong and one of the
implementations handles it gracefully?
-jo
On Sun, Jul 7, 2013 at 11:11 PM, Bruce Guenter wrote:
> On Mon, Jun 24, 2013 at 01:19:08PM +0200, johannes ha
On Mon, Jun 24, 2013 at 01:19:08PM +0200, johannes hanika wrote:
> seems to crash in libjpeg.so.8..?
I ran it through gdb and it crashes in:
#0 0x74353adf in encode_one_block (actbl=0x7fffd42bf040,
dctbl=0x7fffd42ac040, last_dc_val=-261, block=0x7fff4c1ee9b0,
state=0x7fffe96f8670)
Hi,
thanks for the hint. I'll have a closer look.
Ulrich
Am 01.07.2013 20:18, schrieb Pascal Obry:
>
> For the record I had to revert (335d82bf3d) otherwise I had many crashes
> while using the clone iop.
>
> Ulrich, this is your commit, can you have a look? Thanks.
>
>> commit 4489e5fae3d380e6f
For the record I had to revert (335d82bf3d) otherwise I had many crashes
while using the clone iop.
Ulrich, this is your commit, can you have a look? Thanks.
> commit 4489e5fae3d380e6f6edc537e62cd51af6f88f12
> Author: Pascal Obry
> Date: Mon Jul 1 20:13:00 2013 +0200
>
> Revert "fix a fe
On Tue, Jun 25, 2013 at 07:41:23AM -0600, Bruce Guenter wrote:
> On Mon, Jun 24, 2013 at 01:19:08PM +0200, johannes hanika wrote:
> > did anything change in your configuration? especially thread counts
> > and memory limits?
>
> I don't think the background thread count has changed recently, but i
On Mon, Jun 24, 2013 at 01:19:08PM +0200, johannes hanika wrote:
> seems to crash in libjpeg.so.8..?
The libjpeg installed is libjpeg-turbo8:amd64 1.2.1-0ubuntu2, but I am
also using libjpeg-turbo-1.2.1 on my desktop. I have no idea what
libjpeg was in use before upgrading.
> fwiw i can export on
seems to crash in libjpeg.so.8..? fwiw i can export on ubuntu 13.04 just
fine (100s of images not a problem). darktable links to the same dso. did
anything change in your configuration? especially thread counts and memory
limits?
-jo
On Sun, Jun 23, 2013 at 10:04 PM, Bruce Guenter wrote:
>
> I
I am having trouble using darktable (git) on an Ubuntu Gnome 13.04
laptop. All other operations seem to work fine, both in darkroom and
light table, but it crashes during the output stage of exporting -- the
output file is created but contains truncated data.
I have sometimes been able to export
On 1/4/13 6:51 PM, Ulrich Pegelow wrote:
> Am 01.04.2013 17:54, schrieb Moritz Moeller:
>> Using 1.2rc2 on OS X 10.7.5
>>
>> This Lumiere-exported TIFF crashes DT on import.
>> https://www.dropbox.com/s/juacipho9mii095/lumiereExport.tif
>
> Yes, confirmed. Obviously the file is malformatted. I coul
Am 01.04.2013 17:54, schrieb Moritz Moeller:
> Using 1.2rc2 on OS X 10.7.5
>
> This Lumiere-exported TIFF crashes DT on import.
> https://www.dropbox.com/s/juacipho9mii095/lumiereExport.tif
>
Should be fixed now in master.
Ulrich
Am 01.04.2013 17:54, schrieb Moritz Moeller:
> Using 1.2rc2 on OS X 10.7.5
>
> This Lumiere-exported TIFF crashes DT on import.
> https://www.dropbox.com/s/juacipho9mii095/lumiereExport.tif
Yes, confirmed. Obviously the file is malformatted. I could not find any
program that can open bit. Still d
Using 1.2rc2 on OS X 10.7.5
This Lumiere-exported TIFF crashes DT on import.
https://www.dropbox.com/s/juacipho9mii095/lumiereExport.tif
I have issues importing JPGs, they previewfine in the lighttable but
import only the 1st 3rd is loaded into darkroom, the rest imports as
pixel poo. Here is a
then let's remove this part of the functionality for now and let's not
alter legacy_params(). we're trying to get a stable release out soon...
j.
On Mon, Apr 1, 2013 at 11:55 AM, Dennis Gnad wrote:
> Ok, I am sorry, I see the problem, but can't offer a solution that
> doesn't reduce functional
Ok, I am sorry, I see the problem, but can't offer a solution that
doesn't reduce functionality again, I don't know if this is an error
somewhere else in darktable or by design:
The issue is that "legacy_params" gets a dt_iop_module_t* self pointer
but can not (or not always, I thought I had teste
This is the culprit: 0a78638e
The problem is that in legacy_params() we call:
> dt_noiseprofile_t interpolated = dt_iop_denoiseprofile_get_auto_profile(self);
which in turns use self->dev->image_storage, but image_storage is not
initialized at the time legacy_params() is called. This crash dt.
On Thu, 14 Feb 2013 12:22:22 johannes hanika opined:
> well, the final crash is happening in our code handling some gphoto
> stuff, so i guess it might be a valid darktable bug (but i know
> nothing about that part of the code).
I've had a look at this - the hang occurs in gp_camera_get_config ca
well, the final crash is happening in our code handling some gphoto
stuff, so i guess it might be a valid darktable bug (but i know
nothing about that part of the code).
j.
On Thu, Feb 14, 2013 at 6:50 AM, Pascal de Bruijn wrote:
> On Tue, Feb 12, 2013 at 11:46 PM, Kevin wrote:
>> When I start
On Tue, Feb 12, 2013 at 11:46 PM, Kevin wrote:
> When I start dt or dt-cli with my phone attached via USB, dt hangs. If I
> unplug the phone dt aborts - see following stacktrace. Version is latest GIT
> master.
I'm afraid this issue likely isn't directly related to Darktable, but
libgphoto :(.
T
When I start dt or dt-cli with my phone attached via USB, dt hangs. If I
unplug the phone dt aborts - see following stacktrace. Version is latest GIT
master.
#0 0x003fa4a44438 in g_list_remove () from /lib64/libglib-2.0.so.0
#1 0x77cd93ee in _error_func_dispatch (context=,
format=
I confirm, problem solved !
Thanks
Le 08/02/2013 07:43, johannes hanika a écrit :
> should be fixed now, can you retry?
>
> j.
>
> On Fri, Feb 8, 2013 at 10:17 AM, johannes hanika wrote:
>> thanks.
>>
>> and that's a very stupid little error in our code, the string buffer
>> isn't large enough.
should be fixed now, can you retry?
j.
On Fri, Feb 8, 2013 at 10:17 AM, johannes hanika wrote:
> thanks.
>
> and that's a very stupid little error in our code, the string buffer
> isn't large enough. should be very easy to fix, i'll do that as soon
> as i get back to a machine where i can compil
thanks.
and that's a very stupid little error in our code, the string buffer
isn't large enough. should be very easy to fix, i'll do that as soon
as i get back to a machine where i can compile and test..
thanks for reporting.
jo
On Fri, Feb 8, 2013 at 10:08 AM, Florian GOULEAU
wrote:
> Yeah, of
Yeah, of course :
http://pastebin.com/0Yz2XEqD
http://pastebin.com/K9MjyXLP
Sorry for the blinking adds, Free.fr is my internet provider
so I do not see them.
florian
Le 07/02/2013 21:59, johannes hanika a écrit :
> On Fri, Feb 8, 2013 at 9:12 AM, Florian GOULEAU
> wrote:
>> Hello,
>>
>> Well
On Fri, Feb 8, 2013 at 9:12 AM, Florian GOULEAU
wrote:
> Hello,
>
> Well, I removed my darktable directory, .cache/darktable, .config/darktable
> and /opt/darktable
> Then I made a fresh new clone from git, loaded a photo without
> associated xmp
> and still encounter the same crash when playing w
Hello,
Well, I removed my darktable directory, .cache/darktable, .config/darktable
and /opt/darktable
Then I made a fresh new clone from git, loaded a photo without
associated xmp
and still encounter the same crash when playing with custom iop presets.
Here is the output of "darktable -d all" on
works for me. anything special about your setup? old libraries lying
around somewhere in a lib/darktable/ directory?
On Thu, Feb 7, 2013 at 1:42 PM, Florian Gouleau
wrote:
> Hi folks,
>
> current git master crashes when using custom presets in iop.
> To reproduce the problem, use any iop, set the
Hi folks,
current git master crashes when using custom presets in iop.
To reproduce the problem, use any iop, set the parameters as
you want, save them as a custom preset, modify the parameters
and then try to reuse the preset that you just saved.
I have not tried if it applies to the foreseen 1.
On Thu, Dec 6, 2012 at 8:21 PM, David Vincent-Jones
wrote:
> I just moved to "darktable 1.1+51~g99ce9ce" but the error was detected
> on the version immediately prior to this current one.
Ok,
Can you get a backtrace when importing that file?
And can you upload a sample file to somewhere, s
On Thu, Dec 6, 2012 at 6:14 PM, David Vincent-Jones
wrote:
> Importing an exr created in dt
>
> <>
>
> latest ppa version on 64 bit
Which version... Which PPA...
Regards,
Pascal de Bruijn
--
LogMeIn Rescue: Anywhere, An
Importing an exr created in dt
<>
latest ppa version on 64 bit
David
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve you
Hello Ulrich,
I would describe in detail what I did, if I didn't only switch the
pictures. Maybe I toggled the over/under exposure indicator.
BTW I am max_ on irc...
hal
On Sat 24 Nov 2012 12:44:21 PM CET, Ulrich Pegelow wrote:
> Hi,
>
> for some reason dt_dev_pixelpipe_synch() is called with h
Hi,
for some reason dt_dev_pixelpipe_synch() is called with history=0
from dt_dev_pixelpipe_synch_all(). So we need to find out why this happens.
Can you please open a ticket in www.darktable.org/redmine ? The better
you can describe how to provoke the crash the higher the chances it gets
fixed :
Hello,
while switching pictures in dr mode with SAPCE, I sometimes receive a
segfault:
(OpenCL is off because my system crashes reliable with it)
[New Thread 0x7fff53165700 (LWP 5770)]
[New Thread 0x7fff52964700 (LWP 5771)]
[New Thread 0x7fff52163700 (LWP 5772)]
Program received signal SIGSEGV,
exiv2 doesn't like that file:
/home/roumano/raw/2012 09 22 - Barcelone/0063.CR2.xmp
anything special about it?
On Tue, Nov 6, 2012 at 8:19 AM, Roumano wrote:
> Hi,
>
> I have got a crash when i try to import recursively around 1000 raw with
> the current git version (1.0.5 working correctly)
>
Hi,
I have got a crash when i try to import recursively around 1000 raw with
the current git version (1.0.5 working correctly)
My backtrace is usefull ?
If not, please inform me how to get more information ( i have build it
with ./build.sh --buildtype Debug & reinstall glib glibc & gtk+ with
deb
DNG + XMP is in
https://www.dropbox.com/sh/mk3ltjxyc8yd2gr/eRYfChO4In
This is the resp. thread from the crash log:
Thread 5 Crashed:
0 libstdc++.6.dylib 0x7fff87bf7220
std::string::_Rep::_M_grab(std::allocator const&,
std::allocator const&) + 4
1 libstdc++.6.dylib
85 matches
Mail list logo
