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)
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
18 matches
Mail list logo
