[Digikam-devel] [digikam] [Bug 338176] Face Recognition memory allocation crash application

[Christian]

https://bugs.kde.org/show_bug.cgi?id=338176

--- Comment #16 from Christian <gentoo at moin.fi> ---
Dear Gilles - Here's the full Valgrind output. This time, when the digikam used
up all the swap, it somehow logged me out of KDE as well so I couldn't copy the
output from the program itself, but I logged Valgrind output into a file.
Here's the full contents of that. (I had posted the beginning in the Comment
14.)

What's the next step?

==25264== Memcheck, a memory error detector
==25264== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==25264== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==25264== Command: digikam
==25264== Parent PID: 11781
==25264== 
==25264== Thread 5 Thread (pooled):
==25264== Conditional jump or move depends on uninitialised value(s)
==25264==    at 0x2853AC87: picReadHeader(QIODevice*, PICHeader*, bool)
(pic_read.cpp:54)
==25264==    by 0x2853C170: SoftimagePICHandler::canRead(QIODevice*)
(pic_io_handler.cpp:44)
==25264==    by 0x2853B9D4: SoftimagePICPlugin::capabilities(QIODevice*,
QByteArray const&) const (pic_io_plugin.cpp:33)
==25264==    by 0x9AE623B: createReadHandlerHelper(QIODevice*, QByteArray
const&, bool, bool) (qimagereader.cpp:393)
==25264==    by 0x9AE772B: QImageReaderPrivate::initHandler()
(qimagereader.cpp:618)
==25264==    by 0x9AE8C1F: QImageReader::read(QImage*) (qimagereader.cpp:1185)
==25264==    by 0x9AE8DFE: QImageReader::read() (qimagereader.cpp:1155)
==25264==    by 0x9AE3E92: QImage::fromData(unsigned char const*, int, char
const*) (qimage.cpp:5177)
==25264==    by 0x9AE3F4F: QImage::loadFromData(unsigned char const*, int, char
const*) (qimage.cpp:5135)
==25264==    by 0x6D7A8EF: KExiv2Iface::KExiv2::getImagePreview(QImage&) const
(qimage.h:252)
==25264==    by 0x755CF02:
Digikam::PreviewLoadingTask::loadImagePreview(QImage&, QString const&)
(previewtask.cpp:541)
==25264==    by 0x755DC72: Digikam::PreviewLoadingTask::execute()
(previewtask.cpp:288)
==25264== 
==25264== Warning: set address range perms: large range [0x117564040,
0x195984020) (undefined)
==25264== Warning: set address range perms: large range [0x117564028,
0x195984038) (noaccess)
--25264-- core    : 341843968/341843968  max/curr mmap'd, 3/8 unsplit/split sb
unmmap'd,  331321120/301620576 max/curr,     5346371/1998737296
totalloc-blocks/bytes,     4984086 searches 8 rzB
--25264-- dinfo   : 493404160/482103296  max/curr mmap'd, 126/106 unsplit/split
sb unmmap'd,  490909072/479310352 max/curr,     2350709/1775135232
totalloc-blocks/bytes,     2376135 searches 8 rzB
--25264-- client  : 10221268992/10089021440  max/curr mmap'd, 83/1366
unsplit/split sb unmmap'd,  9748533760/9748468192 max/curr,   
30053578/24221816080 totalloc-blocks/bytes,    54708611 searches 24 rzB
--25264-- demangle:    65536/       0  max/curr mmap'd, 0/1 unsplit/split sb
unmmap'd,       128/       0 max/curr,          12/       896
totalloc-blocks/bytes,          11 searches 8 rzB
--25264-- ttaux   : 12075008/11636736  max/curr mmap'd, 53/3 unsplit/split sb
unmmap'd,  11583344/11188272 max/curr,       33696/  31879472
totalloc-blocks/bytes,       33602 searches 8 rzB
==25264== 
==25264==     Valgrind's memory management: out of memory:
==25264==        memcheck:allocate new SecMap's request for 16384 bytes failed.
==25264==        13822648320 bytes have already been allocated.
==25264==     Valgrind cannot continue.  Sorry.
==25264== 
==25264==     There are several possible reasons for this.
==25264==     - You have some kind of memory limit in place.  Look at the
==25264==       output of 'ulimit -a'.  Is there a limit on the size of
==25264==       virtual memory or address space?
==25264==     - You have run out of swap space.
==25264==     - Valgrind has a bug.  If you think this is the case or you are
==25264==     not sure, please let us know and we'll try to fix it.
==25264==     Please note that programs can take substantially more memory than
==25264==     normal when running under Valgrind tools, eg. up to twice or
==25264==     more, depending on the tool.  On a 64-bit machine, Valgrind
==25264==     should be able to make use of up 32GB memory.  On a 32-bit
==25264==     machine, Valgrind should be able to use all the memory available
==25264==     to a single process, up to 4GB if that's how you have your
==25264==     kernel configured.  Most 32-bit Linux setups allow a maximum of
==25264==     3GB per process.
==25264== 
==25264==     Whatever the reason, Valgrind cannot continue.  Sorry.

-- 
You are receiving this mail because:
You are the assignee for the bug.