Mantis

General

block

always

2007-11-24 03:36

2008-10-17 19:59

skirsdeda

high

closed

none

0.2

fixed

DBus timeout for CreateBluetoothSession

If session connecting takes longer time (e.g. devices aren't paired yet), CreateBluetoothSession function times out. To fix this, CreateBluetoothSession should return immediately. OdsSession object should be initialized with invalid fd first and only after socket is connected, it would be assigned to OdsSession object and CONNECTED signal would be emitted.

skirsdeda

2008-01-22 01:10

To maintain Session independence from transport stuff, Session should have public fd property which would be initialized to -1 first. When assigned a valid value, Session would emit CONNECTED signal.

skirsdeda

2008-01-28 19:10

Suggested API change for Manager:
METHODS
string CreateBluetoothSession(string address, string pattern)
     Returns path of Session object instantly (Session is connected after this function returns. Either Connected signal is emitted (Session object) if connection was successful or SessionDisconnected signal is emitted (Manager object) if connecting failed.
SIGNALS
void SessionConnected(object path)
      Signals when session is connected and usable (instead of SessionCreated signal, since sessions are now created even before attempting to connect).

void SessionDisconnected(object path, string error_name, string error_message)
      Signals when session is disconnected or fails to connect initially. error_name and error_message are used only for initial connection failure.

skirsdeda

2008-02-02 19:42

Now I'm thinking that it would be better to introduce Timeout error, which would happen just before DBus timeout so that obex-data-server can do proper cleanup.

RobertRawlins

2008-03-11 20:10

That sounds like a good solution to me, at the moment I get the timeout thrown by dbus but like you say, this doesnt invoke any time of clean up. Iether that or catch the dbus connection and do your cleanup then rethrow your own? make sense?

Robert

heston_james

2008-05-14 10:22

This little bug should be fixed along with the fix for detecting rfcomm timeouts and refusales so we should be killing two birds with one stone when that fix comes along. Because we'll be returning the empty session object immediatly from CreateBluetoothSession() then dbus wont kick up a fuss waiting for a reply whilst we're connecting the RFCOMM sockets.

I'll be working on that fix today so we'll see how things progress, I'll start screaming and waving my arms in the air when I get stuck (which is quite likely).

Heston

heston_james

2008-07-07 15:12

Tadas, this bug is now effectivly resolved due to the changes made for bug 0000053.

General

block

always

2007-12-01 19:22

2008-02-18 14:39

skirsdeda

normal

closed

none

fixed

When link error happens in ServerSession, DISCONNECTED signal should be emitted

Currently only ERROR_OCCURRED is emitted and ServerSession is not finalized (ServerSession objects are finalized in Server object when DISCONNECTED signal is received)

skirsdeda

2007-12-02 14:50

Actually it is possible to close ServerSession by calling Disconnect after link error occurs, so this might not be a bug after all.

skirsdeda

2008-01-22 22:52

ServerSession now emits DISCONNECTED signal if it had link error.

General

block

always

2007-11-30 18:53

2008-02-18 14:39

skirsdeda

high

closed

none

fixed

segmentation fault when closing

Create OPP server, send several files to it, kill obex-data-server. obex-data-server segfaults.

skirsdeda

2007-12-11 17:27

This probably happens due to reference cycles. Therefore, both OdsServer and OdsManager objects should be disposable (also have additional "disposed" signal and is_disposing(bool) private var). Dispose method would finalize all child objects (sessions/servers) and emit "disposed" signal when done.

skirsdeda

2008-01-21 21:50

Fixed as a result of fixing 0000021

General

block

always

2007-11-24 03:45

2008-02-18 14:39

skirsdeda

high

closed

none

fixed

Possible memory leak

OdsManager object has hash tables for sessions and servers where key is DBus owner and value is either session or server information struct. In case the DBus owner creates more than one session/server, older session/server info gets lost because the value is changed in hash table.

skirsdeda

2007-11-30 00:14

Fix in svn.

skirsdeda

2008-01-21 21:48

Now fixed for real, although still needs some thorough testing to confirm.

General

block

always

2007-11-30 18:12

2008-02-18 14:39

skirsdeda

normal

closed

none

fixed

configure.in always enables debug options

there should be --enable-debug switch to enable debug options, otherwise they should be disabled.

skirsdeda

2008-01-24 18:47

Use --enable-debug. When .svn directories present, turned on automatically.

General

block

always

2007-11-30 15:34

2008-02-18 14:39

skirsdeda

normal

closed

none

fixed

ErrorOccurred signal is not used in OdsServer

ErrorOccurred signal should be used in connect_callback()

skirsdeda

2008-01-22 22:52

Fixed in trunk

General

block

always

2007-11-24 03:42

2008-02-18 14:39

skirsdeda

high

closed

none

fixed

Some devices cannot send to ods OPP server

Some devices don't send HDR_BODY header for Object Push command. Although such request should be treated as delete request for FTP server, for OPP it's just a case of buggy client. A workaround should be implemented.

log (107 KB) 2008-01-22 23:37

skirsdeda

2007-11-30 19:04

fixed in svn, have to check though.

skirsdeda

2007-12-02 19:01

Confirmed to fix issue.

skirsdeda

2008-01-21 23:43

** (obex-data-server:11237): WARNING **: Session path: /home/walmis
<walmis> ** Message: Bluetooth address: 00:1A:92:FF:16:0D
<walmis> ** Message: io callback
<walmis> ** Message: event: 1
<walmis> ** Message: event: 2
<walmis> ** Message: CMD_CONNECT requested
<walmis> ** Message: event: 3
<walmis> ** Message: io callback
<walmis> ** Message: event: 1
<walmis> ** Message: event: 11
<walmis> ** Message: header: 203
<walmis> ** Message: header: 1
<walmis> ** Message: HDR_NAME: Resco.Keyboard.PRO.v5.00.ARM.XScale.PPC.Incl.Keygen-SyMPDA.rar
<walmis> ** Message: header: 195
<walmis> ** Message: HDR_LENGTH: 738566
<walmis> ** Message: path: /home/walmis
<walmis> ** Message: Deleting: /home/walmis/Resco.Keyboard.PRO.v5.00.ARM.XScale.PPC.Incl.Keygen-SyMPDA.rar
<walmis> ** Message: event: 3
<walmis> ** Message: io callback
<walmis> ** Message: event: 1
<walmis> ** Message: event: 2
<walmis> ** Message: event: 3
<walmis> ** Message: server session closed
<walmis> ** Message: closing connectio

skirsdeda

2008-01-21 23:43

Same bug, but for FTP

skirsdeda

2008-01-21 23:47

** Message: buf_size: 24327, actual: 0
<walmis> ** Message: event: 3
<walmis> ** Message: io callback
<walmis> ** Message: event: 1
<walmis> ** Message: event: 11
<walmis> ** Message: header: 203
<walmis> ** Message: header: 1
<walmis> ** Message: HDR_NAME: Resco.Keyboard.PRO.v5.00.ARM.XScale.PPC.Incl.Keygen-SyMPDA.rar
<walmis> ** Message: header: 195
<walmis> ** Message: HDR_LENGTH: 738566
<walmis> ** Message: path: /home/walmis
<walmis> ** Message: Deleting: /home/walmis/Resco.Keyboard.PRO.v5.00.ARM.XScale.PPC.Incl.Keygen-SyMPDA.rar
<walmis> ** Message: event: 3
<walmis> ** Message: io callback
<walmis> ** Message: event: 1
<walmis> ** Message: event: 2
<walmis> ** Message: event: 3
<walmis> ** Message: server session closed
<walmis> ** Message: closing connection

skirsdeda

2008-01-21 23:48

for OPP, both using Windows mobile, widcomm stack. Last output is suposed to have "Using delete workaround" line, but doesn't.. Why is this so? Wrong ods version?

skirsdeda

2008-01-24 00:06

This is almost fixed. obex_request_done in ods-session.c still has to be cleaned up because ods_obex_transfer_close is now called in Session/ServerSession instead of readstream/writestream in ods-obex.c. As a result, ods_obex_transfer_close probably doesn't need clean_buffer argument any more.

skirsdeda

2008-01-24 17:29

Fixed in trunk, need to test this

General

block

always

2008-01-18 01:32

2008-02-18 14:39

skirsdeda

high

closed

none

0.2

fixed

rejecting transfer on remote device

About the problem when rejecting transfers from
the phone, we can't fix it without changes to obex-data-server:

This is how it happens:
- we call session created
- we get the prompt on the phone
- press reject on the phone
- the session is created, error occurs (org.openobex.Error.LinkError)
- we connect to the ErrorOccurred signal on the session.
- we fail the Connect because "Another operation in progress"

The session creation should fail, but doesn't...

hadess

2008-01-18 15:24

Sounds similar to:
http://bugs.muiline.com/view.php?id=23 [^]

skirsdeda

2008-01-21 22:27

This is how it should happen:
- Call CreateBluetoothSession ()
- Session is created and automatically connected
- Call SendFile ()
- Get TRANSFER_STARTED signal
- Reject file on remote device
- Get ERROR_OCCURRED signal with error org.openobex.Error.Forbidden (Operation forbidden)
- Call Cancel () and get CANCELLED signal
- Call Disconnect () and get DISCONNECTED signal
- Call Close ()

So Session creation shouldn't fail after all. Current behaviour is correct, although there might be some glitches with specific devices (I'm testing with Sony Ericsson z520i). Maybe you could provide some real test case with code..

ods-dbus-test from test dir in current SVN can be used to try sending file and rejecting it.

401

General

crash

always

2010-03-15 22:13

2010-03-16 13:40

Peri Noid

skirsdeda

normal

resolved

none

0.4.5

no change required

obex-data-server crashes after BT transmission is finished

I'm using obex-data-server invoked by kbluetooth to transfer data to my mobile. unfortunately, everytime I try to transfer a file, after transmission is finished, obex-data-server crashes. Here is a part from dmesg:

obex-data-serve[8803]: segfault at c ip 0805feef sp bfde3480 error 4 in obex-data-server[8048000+1f000]
obex-data-serve[10198]: segfault at 14 ip 0805fef2 sp bf904df0 error 4 in obex-data-server[8048000+1f000]
obex-data-serve[10377]: segfault at 1d8 ip b784a246 sp bfc4fb60 error 4 in libgobject-2.0.so.0.2200.4[b7825000+36000]
obex-data-serve[10395]: segfault at c ip 0805feef sp bf93a060 error 4 in obex-data-server[8048000+1f000]
obex-data-serve[10510]: segfault at c ip 0805feef sp bfec1790 error 4 in obex-data-server (deleted)[8048000+1f000]
obex-data-serve[10553]: segfault at f0 ip b7780246 sp bf9c1990 error 4 in libgobject-2.0.so.0.2200.4[b775b000+36000]
obex-data-serve[10690]: segfault at c ip 0805feef sp bfd7e4c0 error 4 in obex-data-server[8048000+1f000]
obex-data-serve[10711]: segfault at 3f40 ip b7819246 sp bfc6fda0 error 4 in libgobject-2.0.so.0.2200.4[b77f4000+36000]
obex-data-serve[10888]: segfault at c ip 0805feef sp bffc74b0 error 4 in obex-data-server[8048000+1f000]

and obex-data-server dies. In an attachment you can find a strace from one of such executions. I can reproduce it every time. I don't think it is a kbluetooth problem, therefore I'm reporting it here. If you are sure it's just the other way, I'll report it to the KDE team.

obex-data-server.log.gz (11 KB) 2010-03-15 22:13

skirsdeda

2010-03-16 03:55

Please get the newest obex-data-server from svn (svn://muiline.com/obex-data-server/trunk) [^] and get some proper debugging info (detailed info at http://wiki.muiline.com/obex-data-server/reporting_bugs) [^]

Peri Noid

2010-03-16 10:19

OK. Seems to work fine on svn version. Status should be changed to resolved.

163

General

crash

always

2009-07-16 10:59

2009-10-21 20:13

Liskni_si

skirsdeda

normal

closed

none

0.4.4

fixed

ods dies when connecting to non-existing device

When CreateBluetoothSession is called with target address that's not reachable (a bluetooth phone that is off, for example), ods dies after a few seconds instead of emitting SessionConnectError.

skirsdeda

2009-07-16 11:18

Sounds like a serious bug, what version of bluez do you have?

Liskni_si

2009-07-16 11:43

bluez 4.42-2 from Debian unstable

skirsdeda

2009-07-16 11:52

Maybe you could also try running ods with gdb and get stacktrace when ods dies.

Liskni_si

2009-07-16 12:17

Well, it looks like dbus is closing its connection to ods. I don't know why, but it doesn't seem to be your problem, then.

Liskni_si

2009-07-16 12:50

Okay, tracked it. You use strerror in sdp_connect_watch and I have cs_CZ.ISO-8859-2 here. DBus rejects the message with latin2 charset and disconnects ods afterwards. Any idea what's the correct solution for this?

skirsdeda

2009-07-16 16:49

Now we have setlocale(LC_ALL, "") in ods-main.c, however locales should only be used for filenames (if I remember correctly). Filenames are handled with LC_CTYPE while strerror uses LC_MESSAGES setting so maybe we could change setlocale(LC_ALL, "") to setlocale(LC_CTYPE, ""), that way we should get correct filenames and avoid translations from strerror().

Liskni_si

2009-07-16 16:53

Yep, that makes sense.

skirsdeda

2009-07-16 17:07

I commited this change to subversion. Try checking out svn://muiline.com/obex-data-server/trunk [^] and running it instead of system version.

Liskni_si

2009-07-16 17:14

I confirm that it works ok now. Thanks a lot.

skirsdeda

2009-07-16 17:19

Great. I still need to double-check if I haven't broken smth and the it can go to 0.4.5 release. Big thanks for your bug-tracking abilities :)

146

General

crash

have not tried

2008-11-13 20:54

2009-02-08 17:25

skirsdeda

high

closed

none

0.4.2

fixed

Crash when trying to close ServerSession

If ServerSession suspends request to wait for Accept/Reject and client app disconnects from the bus, ods fails to properly close ServerSession.

skirsdeda

2008-11-14 14:32

Fixed in svn rev 2185

144

FTP

crash

always

2008-10-30 02:42

2008-11-01 20:16

skirsdeda

normal

closed

none

fixed

Trying to print NULL pointer in ARM build environment

Same crash reported below.
In case of folder listing, it seems that the remote variable is NULL and incurs a crash when we try to print it in ARM build.
The file is ods-obex.c and the line is followed:

g_message ("name: %s, type: %s", obex_context->remote, obex_context->type);

cheers,

skirsdeda

2008-10-31 23:36

Fixed in svn rev 2142

143

General

crash

always

2008-10-27 15:55

2008-11-01 20:16

ajay

skirsdeda

normal

closed

none

0.4.1

fixed

Crash due to NULL pointer access ( ARM Build) in g_message in file ods-manager.c

When testing on ARM9 Target using Montavista toolchain (v5t) the library crashes when using the Test Application (ods-dbus-test). The crash happens when trying to Push a File via OPP profile with no server channel specified as command line arugments for the Test App(ods-dbus-test).

The crash seems to happen due to NULL pointer access of parsed[1], since the Server channel is not specified. Commenting off the line seems to solve the issue.

Line 687 in ods-manager.c
g_message ("Parsed[0]: %s, Parsed[1]: %s", parsed[0], parsed[1]);

skirsdeda

2008-10-27 16:15

Check if newest svn version works ok.

109

General

crash

always

2008-07-22 13:10

2008-10-17 19:59

heston_james

skirsdeda

normal

closed

none

0.3.1

fixed

Segmentation fault.

After running ODS for a period of time I recieve a segmentation fault out of the blue (no pun intended).

I've reproduced this a few times now, I've attached the valgrind output at the time of the crash.

valgrind output.txt (9 KB) 2008-07-22 13:10
ods_local.txt (79 KB) 2008-07-22 14:27
ods.txt (103 KB) 2008-07-22 16:10

heston_james

2008-07-22 14:26

Skirs, I've attached a more thorough log.

skirsdeda

2008-07-25 03:52

Crash should be gone in newest svn, but definitely not all errors are fixed. Try testing again.

heston_james

2008-07-27 12:32

Hi Skirs,

I was testing this latest SVN build yesterday and recieved a segmentation fault crash. I coulnt confirm if it is this same issue as I wasnt logging my ods output at the time ... d'oh.

If I see it again I'll be sure to make a copy of the output and get it too you.

Heston.

skirsdeda

2008-08-24 00:15

Some fixes regarding this bug in svn revision 1798. It's difficult to test this and I have some other fixes to make so I hope this makes the situation better somehow :)

heston_james

2008-08-24 11:41

Hey Skirs,

I'll test the latest SVN build and let you know how I get on.

Heston

heston_james

2008-08-26 18:25

Afternoon Tadas,

Ok, well I've done some testing on one of our systems here over the weekend and it appears to certainly be much more stable.

In fact, I've not seen it crash once all weekend despite creating thousands of sessions :-).

Due to other reasons I've had to restart the system several times whilst making other modifications to my application so we've not given it a real thorough test, however, before your changes we were generaly seeing segfaults after maybe 200ish sessions, whereas now we're regularly hitting 1000 sessions without fault, I then restart the system for other reasons and the count is reset.

Like you say, you still have changes to make but it certainly seems much more stable now :-)

Thanks for your work on this Tadas, its exciting to see it becoming more stable.

Heston

skirsdeda

2008-08-26 18:44

That's great news. I'm delighted to hear that :)

skirsdeda

2008-10-09 23:29

Closing this since the original problem was probably fixed.

127

BIP

crash

always

2008-08-31 23:49

2008-09-13 02:25

cktakahasi

normal

new

none

0.3.4

open

[BIP] Remote display test crashes the ods

After send the image ods crashes. Tested using ods on both sides(server and client)

SVN revision: 1817

Client dump:
./ods-bip-test.py -r 00:0D:88:BE:89:B0 /home/cktakahasi/Pictures/helsinki.jpg
Sending: /home/cktakahasi/Pictures/helsinki.jpg
-- Encoding = JPEG
-- LocalPath = /home/cktakahasi/Pictures/helsinki.jpg
-- RemoteFilename = helsinki.jpg
-- Type = x-bt/img-img
-- Pixel = 1024*768
-- Size = 92188
Progress: 100%
Transfer completed (Image handle is '0000001')
Sending thumbnail

For more information see the ods/valgrind log in the "additional information" field.

** (obex-data-server:13449): WARNING **: PROGRESS: 81816
** Message: io callback
** Message: event: 8
** Message: obex_writestream
** Message: writestream from File: 9
** Message: event: 8
** Message: obex_writestream
** Message: writestream from File: 9
** Message: event: 0

** (obex-data-server:13449): WARNING **: PROGRESS: 89608
** Message: io callback
** Message: event: 8
** Message: obex_writestream
** Message: writestream from File: 9
** Message: event: 0

** (obex-data-server:13449): WARNING **: PROGRESS: 92188
** Message: io callback
** Message: event: 8
** Message: obex_writestream
** Message: writestream from File: 9
** Message: io callback
** Message: event: 3
** Message: obex_request_done: command 2, response Unknown response
** Message: resize_image_async
** Message: resize_image thread started
==13449==
==13449== Thread 2:
==13449== Invalid read of size 4
==13449== at 0x43E9328: preopen_LTX_get_vtable (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECC19: (within /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECCFE: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4351C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x42329AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x804F777: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449== Address 0x4a48b68 is 0 bytes inside a block of size 36 free'd
==13449== at 0x402265C: free (vg_replace_malloc.c:323)
==13449== by 0x43ECB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4352A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4232974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x8050304: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449==
==13449== Invalid read of size 4
==13449== at 0x43E932E: preopen_LTX_get_vtable (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECC19: (within /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECCFE: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4351C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x42329AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x804F777: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449== Address 0x4a48b84 is 28 bytes inside a block of size 36 free'd
==13449== at 0x402265C: free (vg_replace_malloc.c:323)
==13449== by 0x43ECB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4352A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4232974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x8050304: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449==
==13449== Invalid read of size 4
==13449== at 0x43E991E: lt_dlloader_add (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECC2A: (within /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECCFE: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4351C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x42329AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x804F777: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449== Address 0x4a48b70 is 8 bytes inside a block of size 36 free'd
==13449== at 0x402265C: free (vg_replace_malloc.c:323)
==13449== by 0x43ECB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4352A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4232974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x8050304: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449==
==13449== Invalid read of size 4
==13449== at 0x43E9925: lt_dlloader_add (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECC2A: (within /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECCFE: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4351C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x42329AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x804F777: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449== Address 0x4a48b74 is 12 bytes inside a block of size 36 free'd
==13449== at 0x402265C: free (vg_replace_malloc.c:323)
==13449== by 0x43ECB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4352A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4232974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x8050304: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449==
==13449== Invalid read of size 4
==13449== at 0x43E992C: lt_dlloader_add (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECC2A: (within /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECCFE: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4351C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x42329AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x804F777: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449== Address 0x4a48b78 is 16 bytes inside a block of size 36 free'd
==13449== at 0x402265C: free (vg_replace_malloc.c:323)
==13449== by 0x43ECB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4352A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4232974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x8050304: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449==
==13449== Invalid read of size 4
==13449== at 0x43E9933: lt_dlloader_add (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECC2A: (within /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECCFE: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4351C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x42329AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x804F777: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449== Address 0x4a48b88 is 32 bytes inside a block of size 36 free'd
==13449== at 0x402265C: free (vg_replace_malloc.c:323)
==13449== by 0x43ECB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4352A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4232974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x8050304: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449==
==13449== Invalid read of size 4
==13449== at 0x43E996A: lt_dlloader_add (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECC2A: (within /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECCFE: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4351C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x42329AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x804F777: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449== Address 0x4a48b88 is 32 bytes inside a block of size 36 free'd
==13449== at 0x402265C: free (vg_replace_malloc.c:323)
==13449== by 0x43ECB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4352A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4232974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x8050304: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449==
==13449== Invalid read of size 4
==13449== at 0x43ECC35: (within /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECCFE: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4351C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x42329AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x804F777: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449== Address 0x4a48b7c is 20 bytes inside a block of size 36 free'd
==13449== at 0x402265C: free (vg_replace_malloc.c:323)
==13449== by 0x43ECB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4352A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4232974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x8050304: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449==
==13449== Invalid read of size 4
==13449== at 0x43ECC3C: (within /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECCFE: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4351C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x42329AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x804F777: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449== Address 0x4a48b84 is 28 bytes inside a block of size 36 free'd
==13449== at 0x402265C: free (vg_replace_malloc.c:323)
==13449== by 0x43ECB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4352A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4232974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x8050304: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449==
==13449== Invalid read of size 4
==13449== at 0x43E9798: (within /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ED0A7: lt__slist_find (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43E9760: lt_dlloader_find (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43EC56E: (within /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43EC884: lt_dlopenadvise (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECA24: lt_dlopen (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43E9164: lt_dlpreload_open (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECD30: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4351C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x42329AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==13449== Address 0x4a48b68 is 0 bytes inside a block of size 36 free'd
==13449== at 0x402265C: free (vg_replace_malloc.c:323)
==13449== by 0x43ECB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4352A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4232974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x8050304: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449==
==13449== Invalid read of size 4
==13449== at 0x43EB8F1: (within /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43EC5A7: (within /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43EC884: lt_dlopenadvise (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECA24: lt_dlopen (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43E9164: lt_dlpreload_open (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECD30: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4351C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x42329AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x804F777: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== Address 0x4a48b84 is 28 bytes inside a block of size 36 free'd
==13449== at 0x402265C: free (vg_replace_malloc.c:323)
==13449== by 0x43ECB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4352A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4232974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x8050304: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449==
==13449== Invalid read of size 4
==13449== at 0x43EB8F7: (within /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43EC5A7: (within /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43EC884: lt_dlopenadvise (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECA24: lt_dlopen (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43E9164: lt_dlpreload_open (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECD30: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4351C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x42329AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x804F777: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== Address 0x4a48b70 is 8 bytes inside a block of size 36 free'd
==13449== at 0x402265C: free (vg_replace_malloc.c:323)
==13449== by 0x43ECB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4352A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4232974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x8050304: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449==
==13449== Invalid read of size 4
==13449== at 0x43EAB9D: lt_dlsym (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECD66: (within /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43E916E: lt_dlpreload_open (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECD30: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4351C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x42329AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x804F777: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449== Address 0x4a48b6c is 4 bytes inside a block of size 36 free'd
==13449== at 0x402265C: free (vg_replace_malloc.c:323)
==13449== by 0x43ECB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4352A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4232974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x8050304: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449==
==13449== Invalid read of size 4
==13449== at 0x43EABFB: lt_dlsym (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECD66: (within /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43E916E: lt_dlpreload_open (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECD30: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4351C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x42329AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x804F777: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449== Address 0x4a48b84 is 28 bytes inside a block of size 36 free'd
==13449== at 0x402265C: free (vg_replace_malloc.c:323)
==13449== by 0x43ECB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4352A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4232974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x8050304: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449==
==13449== Invalid read of size 4
==13449== at 0x43EAC1E: lt_dlsym (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECD66: (within /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43E916E: lt_dlpreload_open (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECD30: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4351C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x42329AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x804F777: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449== Address 0x4a48b6c is 4 bytes inside a block of size 36 free'd
==13449== at 0x402265C: free (vg_replace_malloc.c:323)
==13449== by 0x43ECB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4352A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4232974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x8050304: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449==
==13449== Invalid read of size 4
==13449== at 0x43EAC8F: lt_dlsym (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECD66: (within /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43E916E: lt_dlpreload_open (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECD30: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4351C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x42329AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x804F777: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449== Address 0x4a48b78 is 16 bytes inside a block of size 36 free'd
==13449== at 0x402265C: free (vg_replace_malloc.c:323)
==13449== by 0x43ECB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4352A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4232974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x8050304: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449==
==13449== Invalid read of size 4
==13449== at 0x43ED454: dlopen_LTX_get_vtable (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECC19: (within /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43E916E: lt_dlpreload_open (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECD30: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4351C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x42329AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x804F777: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449== Address 0x4a48d88 is 0 bytes inside a block of size 36 free'd
==13449== at 0x402265C: free (vg_replace_malloc.c:323)
==13449== by 0x43ECB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4352A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4232974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x8050304: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449==
==13449== Invalid read of size 4
==13449== at 0x43ED45A: dlopen_LTX_get_vtable (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECC19: (within /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43E916E: lt_dlpreload_open (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECD30: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4351C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x42329AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x804F777: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449== Address 0x4a48da4 is 28 bytes inside a block of size 36 free'd
==13449== at 0x402265C: free (vg_replace_malloc.c:323)
==13449== by 0x43ECB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4352A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4232974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x8050304: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449==
==13449== Invalid read of size 4
==13449== at 0x43E991E: lt_dlloader_add (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECC2A: (within /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43E916E: lt_dlpreload_open (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECD30: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4351C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x42329AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x804F777: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449== Address 0x4a48d90 is 8 bytes inside a block of size 36 free'd
==13449== at 0x402265C: free (vg_replace_malloc.c:323)
==13449== by 0x43ECB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4352A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4232974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x8050304: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449==
==13449== Invalid read of size 4
==13449== at 0x43E9925: lt_dlloader_add (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECC2A: (within /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43E916E: lt_dlpreload_open (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECD30: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4351C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x42329AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x804F777: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449== Address 0x4a48d94 is 12 bytes inside a block of size 36 free'd
==13449== at 0x402265C: free (vg_replace_malloc.c:323)
==13449== by 0x43ECB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4352A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4232974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x8050304: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449==
==13449== Invalid read of size 4
==13449== at 0x43E992C: lt_dlloader_add (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECC2A: (within /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43E916E: lt_dlpreload_open (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECD30: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4351C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x42329AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x804F777: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449== Address 0x4a48d98 is 16 bytes inside a block of size 36 free'd
==13449== at 0x402265C: free (vg_replace_malloc.c:323)
==13449== by 0x43ECB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4352A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4232974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x8050304: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449==
==13449== Invalid read of size 4
==13449== at 0x43E9933: lt_dlloader_add (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECC2A: (within /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43E916E: lt_dlpreload_open (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECD30: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4351C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x42329AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x804F777: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449== Address 0x4a48da8 is 32 bytes inside a block of size 36 free'd
==13449== at 0x402265C: free (vg_replace_malloc.c:323)
==13449== by 0x43ECB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4352A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4232974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x8050304: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449==
==13449== Invalid read of size 4
==13449== at 0x43E996A: lt_dlloader_add (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECC2A: (within /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43E916E: lt_dlpreload_open (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECD30: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4351C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x42329AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x804F777: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449== Address 0x4a48da8 is 32 bytes inside a block of size 36 free'd
==13449== at 0x402265C: free (vg_replace_malloc.c:323)
==13449== by 0x43ECB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4352A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4232974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x8050304: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449==
==13449== Invalid read of size 4
==13449== at 0x43ECC35: (within /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43E916E: lt_dlpreload_open (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECD30: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4351C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x42329AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x804F777: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449== Address 0x4a48d9c is 20 bytes inside a block of size 36 free'd
==13449== at 0x402265C: free (vg_replace_malloc.c:323)
==13449== by 0x43ECB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4352A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434EAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4232974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x8050304: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4563E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13449==
==13449== Invalid read of size 4
==13449== at 0x43EB8F1: (within /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43EC43B: (within /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43EC884: lt_dlopenadvise (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECA24: lt_dlopen (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4351F60: OpenModule (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DCB6: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x433D62C: SetImageInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x42CA53E: ReadImage (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x422E07B: MagickReadImage (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x804F78C: ods_imaging_resize_image (ods-imaging-helpers.c:391)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== Address 0x4a48da4 is not stack'd, malloc'd or (recently) free'd
==13449==
==13449== Invalid read of size 4
==13449== at 0x43EB8F7: (within /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43EC43B: (within /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43EC884: lt_dlopenadvise (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECA24: lt_dlopen (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4351F60: OpenModule (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DCB6: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x433D62C: SetImageInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x42CA53E: ReadImage (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x422E07B: MagickReadImage (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x804F78C: ods_imaging_resize_image (ods-imaging-helpers.c:391)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== Address 0x4a48d90 is not stack'd, malloc'd or (recently) free'd
==13449==
==13449== Jump to the invalid address stated on the next line
==13449== at 0x0: ???
==13449== by 0x43EC43B: (within /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43EC884: lt_dlopenadvise (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECA24: lt_dlopen (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4351F60: OpenModule (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DCB6: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x433D62C: SetImageInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x42CA53E: ReadImage (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x422E07B: MagickReadImage (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x804F78C: ods_imaging_resize_image (ods-imaging-helpers.c:391)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==13449==
==13449== Process terminating with default action of signal 11 (SIGSEGV)
==13449== Bad permissions for mapped region at address 0x0
==13449== at 0x0: ???
==13449== by 0x43EC43B: (within /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43EC884: lt_dlopenadvise (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x43ECA24: lt_dlopen (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x4351F60: OpenModule (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x434DCB6: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x433D62C: SetImageInfo (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x42CA53E: ReadImage (in /usr/lib/libMagick.so.10.0.9)
==13449== by 0x422E07B: MagickReadImage (in /usr/lib/libWand.so.10.0.9)
==13449== by 0x804F78C: ods_imaging_resize_image (ods-imaging-helpers.c:391)
==13449== by 0x40DCE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x447A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449==
==13449== ERROR SUMMARY: 48 errors from 44 contexts (suppressed: 83 from 1)
==13449== malloc/free: in use at exit: 339,554 bytes in 3,605 blocks.
==13449== malloc/free: 35,191 allocs, 31,586 frees, 153,151,651 bytes allocated.
==13449== For counts of detected errors, rerun with: -v
==13449== searching for pointers to 3,605 not-freed blocks.
==13449== checked 9,303,320 bytes.
==13449==
==13449== Thread 1:
==13449==
==13449== 32 (8 direct, 24 indirect) bytes in 1 blocks are definitely lost in loss record 5 of 35
==13449== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==13449== by 0x419AC2A: sdp_list_append (sdp.c:1544)
==13449== by 0x419B054: sdp_get_access_protos (sdp.c:1680)
==13449== by 0x804D4EB: get_remote_service_record_cb (ods-bluez.c:355)
==13449== by 0x414833E: (within /usr/lib/libdbus-glib-1.so.2.1.0)
==13449== by 0x4173E00: (within /usr/lib/libdbus-1.so.3.4.0)
==13449== by 0x4163B52: (within /usr/lib/libdbus-1.so.3.4.0)
==13449== by 0x41656F8: dbus_connection_dispatch (in /usr/lib/libdbus-1.so.3.4.0)
==13449== by 0x41444CC: (within /usr/lib/libdbus-glib-1.so.2.1.0)
==13449== by 0x40B4DD5: g_main_context_dispatch (in /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x40B8192: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x40B8576: g_main_loop_run (in /usr/lib/libglib-2.0.so.0.1600.4)
==13449==
==13449==
==13449== 12 bytes in 1 blocks are definitely lost in loss record 6 of 35
==13449== at 0x4021BDE: calloc (vg_replace_malloc.c:397)
==13449== by 0x40BCD54: g_malloc0 (in /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x804F653: ods_imaging_get_image_info_async (ods-imaging-helpers.c:510)
==13449== by 0x805B5C3: ods_session_put_image (ods-session.c:1645)
==13449== by 0x4147B46: (within /usr/lib/libdbus-glib-1.so.2.1.0)
==13449== by 0x417369A: (within /usr/lib/libdbus-1.so.3.4.0)
==13449== by 0x4165A65: dbus_connection_dispatch (in /usr/lib/libdbus-1.so.3.4.0)
==13449== by 0x41444CC: (within /usr/lib/libdbus-glib-1.so.2.1.0)
==13449== by 0x40B4DD5: g_main_context_dispatch (in /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x40B8192: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x40B8576: g_main_loop_run (in /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x8050657: main (ods-main.c:188)
==13449==
==13449==
==13449== 800 bytes in 20 blocks are possibly lost in loss record 13 of 35
==13449== at 0x4021BDE: calloc (vg_replace_malloc.c:397)
==13449== by 0x40BCD54: g_malloc0 (in /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x4064304: (within /usr/lib/libgobject-2.0.so.0.1600.4)
==13449== by 0x40644A4: (within /usr/lib/libgobject-2.0.so.0.1600.4)
==13449== by 0x40671DF: g_type_init_with_debug_flags (in /usr/lib/libgobject-2.0.so.0.1600.4)
==13449== by 0x4067341: g_type_init (in /usr/lib/libgobject-2.0.so.0.1600.4)
==13449== by 0x805048C: main (ods-main.c:131)
==13449==
==13449==
==13449== 1,174 (32 direct, 1,142 indirect) bytes in 1 blocks are definitely lost in loss record 14 of 35
==13449== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==13449== by 0x419DA62: sdp_record_alloc (sdp.c:2907)
==13449== by 0x419A62F: sdp_extract_pdu_safe (sdp.c:1331)
==13449== by 0x419A7E2: sdp_extract_pdu (sdp.c:1393)
==13449== by 0x804D4D6: get_remote_service_record_cb (ods-bluez.c:352)
==13449== by 0x414833E: (within /usr/lib/libdbus-glib-1.so.2.1.0)
==13449== by 0x4173E00: (within /usr/lib/libdbus-1.so.3.4.0)
==13449== by 0x4163B52: (within /usr/lib/libdbus-1.so.3.4.0)
==13449== by 0x41656F8: dbus_connection_dispatch (in /usr/lib/libdbus-1.so.3.4.0)
==13449== by 0x41444CC: (within /usr/lib/libdbus-glib-1.so.2.1.0)
==13449== by 0x40B4DD5: g_main_context_dispatch (in /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x40B8192: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449==
==13449==
==13449== 144 bytes in 1 blocks are possibly lost in loss record 17 of 35
==13449== at 0x4021BDE: calloc (vg_replace_malloc.c:397)
==13449== by 0x4010627: (within /lib/ld-2.7.so)
==13449== by 0x40106EB: _dl_allocate_tls (in /lib/ld-2.7.so)
==13449== by 0x447AC3C: pthread_create@@GLIBC_2.1 (in /lib/tls/i686/cmov/libpthread-2.7.so)
==13449== by 0x4130D1F: (within /usr/lib/libgthread-2.0.so.0.1600.4)
==13449== by 0x40DCD0B: g_thread_create_full (in /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x804F69B: ods_imaging_get_image_info_async (ods-imaging-helpers.c:515)
==13449== by 0x805B5C3: ods_session_put_image (ods-session.c:1645)
==13449== by 0x4147B46: (within /usr/lib/libdbus-glib-1.so.2.1.0)
==13449== by 0x417369A: (within /usr/lib/libdbus-1.so.3.4.0)
==13449== by 0x4165A65: dbus_connection_dispatch (in /usr/lib/libdbus-1.so.3.4.0)
==13449== by 0x41444CC: (within /usr/lib/libdbus-glib-1.so.2.1.0)
==13449==
==13449==
==13449== 5,032 bytes in 11 blocks are possibly lost in loss record 29 of 35
==13449== at 0x4021A92: memalign (vg_replace_malloc.c:460)
==13449== by 0x4021B3F: posix_memalign (vg_replace_malloc.c:569)
==13449== by 0x40D1473: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x40D26A0: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x408F50E: g_array_sized_new (in /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x408F616: g_array_new (in /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x40DD7A0: g_static_private_set (in /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x409ED3F: g_get_filename_charsets (in /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x409EDB0: (within /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x40DDA59: g_thread_init_glib (in /usr/lib/libglib-2.0.so.0.1600.4)
==13449== by 0x4131636: g_thread_init (in /usr/lib/libgthread-2.0.so.0.1600.4)
==13449== by 0x805043B: main (ods-main.c:120)
==13449==
==13449== LEAK SUMMARY:
==13449== definitely lost: 52 bytes in 3 blocks.
==13449== indirectly lost: 1,166 bytes in 55 blocks.
==13449== possibly lost: 5,976 bytes in 32 blocks.
==13449== still reachable: 332,360 bytes in 3,515 blocks.
==13449== suppressed: 0 bytes in 0 blocks.
==13449== Reachable blocks (those to which a pointer was found) are not shown.
==13449== To see them, rerun with: --leak-check=full --show-reachable=yes
Killed

125

BIP

crash

sometimes

2008-08-31 22:19

2008-09-13 02:25

cktakahasi

normal

new

none

0.3.4

open

[BIP] Imaging resize is crashing

Imaging resize doesn't work. See attached log in the additional information field.

SVN repository revision: 1817
libmagick9-dev 7:6.3.7.9.dfsg1-2ubuntu1

Crash reproduced using ./ods-bip-test.py --size=768*460 00:0C:55:BC:10:85 image.jpg

==9654== Memcheck, a memory error detector.
==9654== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==9654== Using LibVEX rev 1804, a library for dynamic binary translation.
==9654== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==9654== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation framework.
==9654== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==9654== For more details, rerun with: -v
==9654==
** Message: obex-data-server 0.4svn
** Message: Using Session bus
** Message: Parsed[0]: bip, Parsed[1]: (null)
** Message: supp_capabilities: 0
** Message: supp_features: 1
** Message: supp_funcs: 3
** Message: data_cap: 3072000
** Message: Connecting to 00:0C:55:BC:10:85 using channel 3
** Message: Connect in progress
** Message: Connected
** Message: Imaging SDP data:
** Message: >> capabilities: 0
** Message: >> features: 1
** Message: >> functions: 3
** Message: >> capacity: 3072000
** Message: Session created by: :1.70
** Message: io callback
** Message: event: 3
** Message: obex_request_done: command 0, response OK, Success
** Message: LOCK
==9654== Thread 2:
==9654== Invalid read of size 4
==9654== at 0x4015091: (within /lib/ld-2.7.so)
==9654== by 0x400D5D5: (within /lib/ld-2.7.so)
==9654== by 0x4010F5D: (within /lib/ld-2.7.so)
==9654== by 0x4802C18: (within /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x400D5D5: (within /lib/ld-2.7.so)
==9654== by 0x48032BB: (within /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x4802B50: dlopen (in /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x43EE5D2: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EC8F9: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ED43B: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ED884: lt_dlopenadvise (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDA24: lt_dlopen (in /usr/lib/libMagick.so.10.0.9)
==9654== Address 0x581b004 is 4 bytes inside a block of size 7 alloc'd
==9654== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==9654== by 0x43EA5D1: lt__malloc (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EC7D4: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ED3F9: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ED884: lt_dlopenadvise (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDA24: lt_dlopen (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4352F60: OpenModule (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434ECB6: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x433E62C: SetImageInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x42CB53E: ReadImage (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x422F07B: MagickReadImage (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x80502F0: ods_imaging_get_image_info (ods-imaging-helpers.c:354)
==9654==
==9654== Invalid read of size 4
==9654== at 0x4015091: (within /lib/ld-2.7.so)
==9654== by 0x4011543: (within /lib/ld-2.7.so)
==9654== by 0x400D5D5: (within /lib/ld-2.7.so)
==9654== by 0x4010F5D: (within /lib/ld-2.7.so)
==9654== by 0x4802C18: (within /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x400D5D5: (within /lib/ld-2.7.so)
==9654== by 0x48032BB: (within /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x4802B50: dlopen (in /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x43EE5D2: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EC8F9: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ED43B: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ED884: lt_dlopenadvise (in /usr/lib/libMagick.so.10.0.9)
==9654== Address 0x581b004 is 4 bytes inside a block of size 7 alloc'd
==9654== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==9654== by 0x43EA5D1: lt__malloc (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EC7D4: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ED3F9: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ED884: lt_dlopenadvise (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDA24: lt_dlopen (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4352F60: OpenModule (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434ECB6: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x433E62C: SetImageInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x42CB53E: ReadImage (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x422F07B: MagickReadImage (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x80502F0: ods_imaging_get_image_info (ods-imaging-helpers.c:354)
==9654==
==9654== Invalid read of size 4
==9654== at 0x4015209: (within /lib/ld-2.7.so)
==9654== by 0x4011543: (within /lib/ld-2.7.so)
==9654== by 0x400D5D5: (within /lib/ld-2.7.so)
==9654== by 0x4010F5D: (within /lib/ld-2.7.so)
==9654== by 0x4802C18: (within /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x400D5D5: (within /lib/ld-2.7.so)
==9654== by 0x48032BB: (within /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x4802B50: dlopen (in /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x43EE5D2: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EC8F9: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ED43B: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ED884: lt_dlopenadvise (in /usr/lib/libMagick.so.10.0.9)
==9654== Address 0x581b004 is 4 bytes inside a block of size 7 alloc'd
==9654== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==9654== by 0x43EA5D1: lt__malloc (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EC7D4: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ED3F9: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ED884: lt_dlopenadvise (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDA24: lt_dlopen (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4352F60: OpenModule (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434ECB6: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x433E62C: SetImageInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x42CB53E: ReadImage (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x422F07B: MagickReadImage (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x80502F0: ods_imaging_get_image_info (ods-imaging-helpers.c:354)
==9654==
==9654== Invalid read of size 4
==9654== at 0x4015209: (within /lib/ld-2.7.so)
==9654== by 0x4008268: (within /lib/ld-2.7.so)
==9654== by 0x4011543: (within /lib/ld-2.7.so)
==9654== by 0x400D5D5: (within /lib/ld-2.7.so)
==9654== by 0x4010F5D: (within /lib/ld-2.7.so)
==9654== by 0x4802C18: (within /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x400D5D5: (within /lib/ld-2.7.so)
==9654== by 0x48032BB: (within /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x4802B50: dlopen (in /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x43EE5D2: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EC8F9: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ED43B: (within /usr/lib/libMagick.so.10.0.9)
==9654== Address 0x581b004 is 4 bytes inside a block of size 7 alloc'd
==9654== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==9654== by 0x43EA5D1: lt__malloc (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EC7D4: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ED3F9: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ED884: lt_dlopenadvise (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDA24: lt_dlopen (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4352F60: OpenModule (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434ECB6: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x433E62C: SetImageInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x42CB53E: ReadImage (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x422F07B: MagickReadImage (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x80502F0: ods_imaging_get_image_info (ods-imaging-helpers.c:354)
==9654==
==9654== Invalid read of size 4
==9654== at 0x4015209: (within /lib/ld-2.7.so)
==9654== by 0x4802C18: (within /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x400D5D5: (within /lib/ld-2.7.so)
==9654== by 0x48032BB: (within /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x4802B50: dlopen (in /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x43EE5D2: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EC8F9: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ED43B: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ED884: lt_dlopenadvise (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDA24: lt_dlopen (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4352F60: OpenModule (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434ECB6: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== Address 0x5c5f1a4 is 36 bytes inside a block of size 38 alloc'd
==9654== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==9654== by 0x400D6E3: (within /lib/ld-2.7.so)
==9654== by 0x4008268: (within /lib/ld-2.7.so)
==9654== by 0x4011543: (within /lib/ld-2.7.so)
==9654== by 0x400D5D5: (within /lib/ld-2.7.so)
==9654== by 0x4010F5D: (within /lib/ld-2.7.so)
==9654== by 0x4802C18: (within /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x400D5D5: (within /lib/ld-2.7.so)
==9654== by 0x48032BB: (within /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x4802B50: dlopen (in /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x43EE5D2: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EC8F9: (within /usr/lib/libMagick.so.10.0.9)
==9654==
==9654== Conditional jump or move depends on uninitialised value(s)
==9654== at 0x4015213: (within /lib/ld-2.7.so)
==9654== by 0x4011108: (within /lib/ld-2.7.so)
==9654== by 0x4802C18: (within /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x400D5D5: (within /lib/ld-2.7.so)
==9654== by 0x48032BB: (within /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x4802B50: dlopen (in /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x43EE5D2: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EC8F9: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ED43B: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ED884: lt_dlopenadvise (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDA24: lt_dlopen (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4352F60: OpenModule (in /usr/lib/libMagick.so.10.0.9)
==9654==
==9654== Conditional jump or move depends on uninitialised value(s)
==9654== at 0x401521E: (within /lib/ld-2.7.so)
==9654== by 0x4011108: (within /lib/ld-2.7.so)
==9654== by 0x4802C18: (within /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x400D5D5: (within /lib/ld-2.7.so)
==9654== by 0x48032BB: (within /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x4802B50: dlopen (in /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x43EE5D2: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EC8F9: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ED43B: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ED884: lt_dlopenadvise (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDA24: lt_dlopen (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4352F60: OpenModule (in /usr/lib/libMagick.so.10.0.9)
==9654==
==9654== Invalid read of size 4
==9654== at 0x4015091: (within /lib/ld-2.7.so)
==9654== by 0x40079D9: (within /lib/ld-2.7.so)
==9654== by 0x4011543: (within /lib/ld-2.7.so)
==9654== by 0x400D5D5: (within /lib/ld-2.7.so)
==9654== by 0x4010F5D: (within /lib/ld-2.7.so)
==9654== by 0x4802C18: (within /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x400D5D5: (within /lib/ld-2.7.so)
==9654== by 0x48032BB: (within /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x4802B50: dlopen (in /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x43EE5D2: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EC8F9: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ECBA4: (within /usr/lib/libMagick.so.10.0.9)
==9654== Address 0x4a2368c is 52 bytes inside a block of size 54 alloc'd
==9654== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==9654== by 0x43EA5D1: lt__malloc (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ECAE3: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ED6BF: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ED884: lt_dlopenadvise (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDA24: lt_dlopen (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4352F60: OpenModule (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434ECB6: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x433E62C: SetImageInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x42CB53E: ReadImage (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x422F07B: MagickReadImage (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x80502F0: ods_imaging_get_image_info (ods-imaging-helpers.c:354)
==9654==
==9654== Invalid read of size 4
==9654== at 0x4015209: (within /lib/ld-2.7.so)
==9654== by 0x40079D9: (within /lib/ld-2.7.so)
==9654== by 0x4011543: (within /lib/ld-2.7.so)
==9654== by 0x400D5D5: (within /lib/ld-2.7.so)
==9654== by 0x4010F5D: (within /lib/ld-2.7.so)
==9654== by 0x4802C18: (within /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x400D5D5: (within /lib/ld-2.7.so)
==9654== by 0x48032BB: (within /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x4802B50: dlopen (in /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x43EE5D2: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EC8F9: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ECBA4: (within /usr/lib/libMagick.so.10.0.9)
==9654== Address 0x4a2368c is 52 bytes inside a block of size 54 alloc'd
==9654== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==9654== by 0x43EA5D1: lt__malloc (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ECAE3: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ED6BF: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ED884: lt_dlopenadvise (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDA24: lt_dlopen (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4352F60: OpenModule (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434ECB6: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x433E62C: SetImageInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x42CB53E: ReadImage (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x422F07B: MagickReadImage (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x80502F0: ods_imaging_get_image_info (ods-imaging-helpers.c:354)
==9654==
==9654== Invalid read of size 4
==9654== at 0x4015209: (within /lib/ld-2.7.so)
==9654== by 0x4005C69: (within /lib/ld-2.7.so)
==9654== by 0x4007A97: (within /lib/ld-2.7.so)
==9654== by 0x4011543: (within /lib/ld-2.7.so)
==9654== by 0x400D5D5: (within /lib/ld-2.7.so)
==9654== by 0x4010F5D: (within /lib/ld-2.7.so)
==9654== by 0x4802C18: (within /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x400D5D5: (within /lib/ld-2.7.so)
==9654== by 0x48032BB: (within /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x4802B50: dlopen (in /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x43EE5D2: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EC8F9: (within /usr/lib/libMagick.so.10.0.9)
==9654== Address 0x4a2368c is 52 bytes inside a block of size 54 alloc'd
==9654== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==9654== by 0x43EA5D1: lt__malloc (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ECAE3: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ED6BF: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ED884: lt_dlopenadvise (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDA24: lt_dlopen (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4352F60: OpenModule (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434ECB6: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x433E62C: SetImageInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x42CB53E: ReadImage (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x422F07B: MagickReadImage (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x80502F0: ods_imaging_get_image_info (ods-imaging-helpers.c:354)
==9654==
==9654== Conditional jump or move depends on uninitialised value(s)
==9654== at 0x401522A: (within /lib/ld-2.7.so)
==9654== by 0x459C694: (within /lib/tls/i686/cmov/libc-2.7.so)
==9654== by 0x459CA29: _dl_sym (in /lib/tls/i686/cmov/libc-2.7.so)
==9654== by 0x4802DE7: (within /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x400D5D5: (within /lib/ld-2.7.so)
==9654== by 0x48032BB: (within /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x4802D72: dlsym (in /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x43EE518: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EBC91: lt_dlsym (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43530AD: OpenModule (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434ECB6: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x433E62C: SetImageInfo (in /usr/lib/libMagick.so.10.0.9)
==9654==
==9654== Invalid read of size 4
==9654== at 0x4015209: (within /lib/ld-2.7.so)
==9654== by 0x400D8D9: (within /lib/ld-2.7.so)
==9654== by 0x4009A66: (within /lib/ld-2.7.so)
==9654== by 0x459C694: (within /lib/tls/i686/cmov/libc-2.7.so)
==9654== by 0x459CA29: _dl_sym (in /lib/tls/i686/cmov/libc-2.7.so)
==9654== by 0x4802DE7: (within /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x400D5D5: (within /lib/ld-2.7.so)
==9654== by 0x48032BB: (within /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x4802D72: dlsym (in /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x43EE518: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EBC91: lt_dlsym (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43530AD: OpenModule (in /usr/lib/libMagick.so.10.0.9)
==9654== Address 0x4a238ac is 52 bytes inside a block of size 54 alloc'd
==9654== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==9654== by 0x4006FD4: (within /lib/ld-2.7.so)
==9654== by 0x40079D9: (within /lib/ld-2.7.so)
==9654== by 0x4011543: (within /lib/ld-2.7.so)
==9654== by 0x400D5D5: (within /lib/ld-2.7.so)
==9654== by 0x4010F5D: (within /lib/ld-2.7.so)
==9654== by 0x4802C18: (within /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x400D5D5: (within /lib/ld-2.7.so)
==9654== by 0x48032BB: (within /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x4802B50: dlopen (in /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x43EE5D2: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EC8F9: (within /usr/lib/libMagick.so.10.0.9)
==9654==
==9654== Conditional jump or move depends on uninitialised value(s)
==9654== at 0x4015241: (within /lib/ld-2.7.so)
==9654== by 0x459C694: (within /lib/tls/i686/cmov/libc-2.7.so)
==9654== by 0x459CA29: _dl_sym (in /lib/tls/i686/cmov/libc-2.7.so)
==9654== by 0x4802DE7: (within /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x400D5D5: (within /lib/ld-2.7.so)
==9654== by 0x48032BB: (within /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x4802D72: dlsym (in /lib/tls/i686/cmov/libdl-2.7.so)
==9654== by 0x43EE518: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EBC91: lt_dlsym (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4353143: OpenModule (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434ECB6: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x433E62C: SetImageInfo (in /usr/lib/libMagick.so.10.0.9)
** Message: UNLOCK
** Message: LOCK
** Message: resize_image_async
** Message: resize_image thread started
==9654==
==9654== Thread 3:
==9654== Invalid read of size 4
==9654== at 0x43EA328: preopen_LTX_get_vtable (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDC19: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDCFE: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4352C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x42339AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x80503D1: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654== Address 0x4a2e9a0 is 0 bytes inside a block of size 36 free'd
==9654== at 0x402265C: free (vg_replace_malloc.c:323)
==9654== by 0x43EDB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4353A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4233974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x805036E: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654==
==9654== Invalid read of size 4
==9654== at 0x43EA32E: preopen_LTX_get_vtable (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDC19: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDCFE: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4352C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x42339AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x80503D1: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654== Address 0x4a2e9bc is 28 bytes inside a block of size 36 free'd
==9654== at 0x402265C: free (vg_replace_malloc.c:323)
==9654== by 0x43EDB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4353A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4233974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x805036E: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654==
==9654== Invalid read of size 4
==9654== at 0x43EA91E: lt_dlloader_add (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDC2A: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDCFE: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4352C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x42339AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x80503D1: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654== Address 0x4a2e9a8 is 8 bytes inside a block of size 36 free'd
==9654== at 0x402265C: free (vg_replace_malloc.c:323)
==9654== by 0x43EDB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4353A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4233974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x805036E: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654==
==9654== Invalid read of size 4
==9654== at 0x43EA925: lt_dlloader_add (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDC2A: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDCFE: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4352C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x42339AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x80503D1: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654== Address 0x4a2e9ac is 12 bytes inside a block of size 36 free'd
==9654== at 0x402265C: free (vg_replace_malloc.c:323)
==9654== by 0x43EDB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4353A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4233974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x805036E: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654==
==9654== Invalid read of size 4
==9654== at 0x43EA92C: lt_dlloader_add (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDC2A: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDCFE: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4352C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x42339AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x80503D1: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654== Address 0x4a2e9b0 is 16 bytes inside a block of size 36 free'd
==9654== at 0x402265C: free (vg_replace_malloc.c:323)
==9654== by 0x43EDB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4353A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4233974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x805036E: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654==
==9654== Invalid read of size 4
==9654== at 0x43EA933: lt_dlloader_add (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDC2A: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDCFE: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4352C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x42339AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x80503D1: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654== Address 0x4a2e9c0 is 32 bytes inside a block of size 36 free'd
==9654== at 0x402265C: free (vg_replace_malloc.c:323)
==9654== by 0x43EDB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4353A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4233974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x805036E: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654==
==9654== Invalid read of size 4
==9654== at 0x43EA96A: lt_dlloader_add (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDC2A: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDCFE: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4352C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x42339AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x80503D1: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654== Address 0x4a2e9c0 is 32 bytes inside a block of size 36 free'd
==9654== at 0x402265C: free (vg_replace_malloc.c:323)
==9654== by 0x43EDB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4353A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4233974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x805036E: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654==
==9654== Invalid read of size 4
==9654== at 0x43EDC35: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDCFE: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4352C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x42339AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x80503D1: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654== Address 0x4a2e9b4 is 20 bytes inside a block of size 36 free'd
==9654== at 0x402265C: free (vg_replace_malloc.c:323)
==9654== by 0x43EDB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4353A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4233974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x805036E: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654==
==9654== Invalid read of size 4
==9654== at 0x43EDC3C: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDCFE: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4352C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x42339AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x80503D1: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654== Address 0x4a2e9bc is 28 bytes inside a block of size 36 free'd
==9654== at 0x402265C: free (vg_replace_malloc.c:323)
==9654== by 0x43EDB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4353A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4233974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x805036E: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654==
==9654== Invalid read of size 4
==9654== at 0x43EA798: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EE0A7: lt__slist_find (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EA760: lt_dlloader_find (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ED56E: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ED884: lt_dlopenadvise (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDA24: lt_dlopen (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EA164: lt_dlpreload_open (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDD30: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4352C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x42339AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==9654== Address 0x4a2e9a0 is 0 bytes inside a block of size 36 free'd
==9654== at 0x402265C: free (vg_replace_malloc.c:323)
==9654== by 0x43EDB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4353A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4233974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x805036E: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654==
==9654== Invalid read of size 4
==9654== at 0x43EC8F1: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ED5A7: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ED884: lt_dlopenadvise (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDA24: lt_dlopen (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EA164: lt_dlpreload_open (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDD30: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4352C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x42339AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x80503D1: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== Address 0x4a2e9bc is 28 bytes inside a block of size 36 free'd
==9654== at 0x402265C: free (vg_replace_malloc.c:323)
==9654== by 0x43EDB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4353A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4233974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x805036E: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654==
==9654== Invalid read of size 4
==9654== at 0x43EC8F7: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ED5A7: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ED884: lt_dlopenadvise (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDA24: lt_dlopen (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EA164: lt_dlpreload_open (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDD30: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4352C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x42339AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x80503D1: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== Address 0x4a2e9a8 is 8 bytes inside a block of size 36 free'd
==9654== at 0x402265C: free (vg_replace_malloc.c:323)
==9654== by 0x43EDB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4353A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4233974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x805036E: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654==
==9654== Invalid read of size 4
==9654== at 0x43EBB9D: lt_dlsym (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDD66: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EA16E: lt_dlpreload_open (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDD30: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4352C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x42339AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x80503D1: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654== Address 0x4a2e9a4 is 4 bytes inside a block of size 36 free'd
==9654== at 0x402265C: free (vg_replace_malloc.c:323)
==9654== by 0x43EDB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4353A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4233974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x805036E: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654==
==9654== Invalid read of size 4
==9654== at 0x43EBBFB: lt_dlsym (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDD66: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EA16E: lt_dlpreload_open (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDD30: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4352C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x42339AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x80503D1: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654== Address 0x4a2e9bc is 28 bytes inside a block of size 36 free'd
==9654== at 0x402265C: free (vg_replace_malloc.c:323)
==9654== by 0x43EDB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4353A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4233974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x805036E: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654==
==9654== Invalid read of size 4
==9654== at 0x43EBC1E: lt_dlsym (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDD66: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EA16E: lt_dlpreload_open (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDD30: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4352C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x42339AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x80503D1: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654== Address 0x4a2e9a4 is 4 bytes inside a block of size 36 free'd
==9654== at 0x402265C: free (vg_replace_malloc.c:323)
==9654== by 0x43EDB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4353A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4233974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x805036E: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654==
==9654== Invalid read of size 4
==9654== at 0x43EBC8F: lt_dlsym (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDD66: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EA16E: lt_dlpreload_open (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDD30: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4352C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x42339AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x80503D1: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654== Address 0x4a2e9b0 is 16 bytes inside a block of size 36 free'd
==9654== at 0x402265C: free (vg_replace_malloc.c:323)
==9654== by 0x43EDB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4353A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4233974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x805036E: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654==
==9654== Invalid read of size 4
==9654== at 0x43EE454: dlopen_LTX_get_vtable (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDC19: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EA16E: lt_dlpreload_open (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDD30: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4352C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x42339AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x80503D1: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654== Address 0x4a2ebc0 is 0 bytes inside a block of size 36 free'd
==9654== at 0x402265C: free (vg_replace_malloc.c:323)
==9654== by 0x43EDB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4353A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4233974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x805036E: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654==
==9654== Invalid read of size 4
==9654== at 0x43EE45A: dlopen_LTX_get_vtable (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDC19: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EA16E: lt_dlpreload_open (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDD30: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4352C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x42339AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x80503D1: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654== Address 0x4a2ebdc is 28 bytes inside a block of size 36 free'd
==9654== at 0x402265C: free (vg_replace_malloc.c:323)
==9654== by 0x43EDB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4353A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4233974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x805036E: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654==
==9654== Invalid read of size 4
==9654== at 0x43EA91E: lt_dlloader_add (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDC2A: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EA16E: lt_dlpreload_open (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDD30: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4352C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x42339AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x80503D1: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654== Address 0x4a2ebc8 is 8 bytes inside a block of size 36 free'd
==9654== at 0x402265C: free (vg_replace_malloc.c:323)
==9654== by 0x43EDB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4353A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4233974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x805036E: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654==
==9654== Invalid read of size 4
==9654== at 0x43EA925: lt_dlloader_add (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDC2A: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EA16E: lt_dlpreload_open (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDD30: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4352C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x42339AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x80503D1: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654== Address 0x4a2ebcc is 12 bytes inside a block of size 36 free'd
==9654== at 0x402265C: free (vg_replace_malloc.c:323)
==9654== by 0x43EDB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4353A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4233974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x805036E: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654==
==9654== Invalid read of size 4
==9654== at 0x43EA92C: lt_dlloader_add (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDC2A: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EA16E: lt_dlpreload_open (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDD30: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4352C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x42339AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x80503D1: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654== Address 0x4a2ebd0 is 16 bytes inside a block of size 36 free'd
==9654== at 0x402265C: free (vg_replace_malloc.c:323)
==9654== by 0x43EDB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4353A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4233974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x805036E: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654==
==9654== Invalid read of size 4
==9654== at 0x43EA933: lt_dlloader_add (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDC2A: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EA16E: lt_dlpreload_open (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDD30: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4352C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x42339AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x80503D1: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654== Address 0x4a2ebe0 is 32 bytes inside a block of size 36 free'd
==9654== at 0x402265C: free (vg_replace_malloc.c:323)
==9654== by 0x43EDB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4353A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4233974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x805036E: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654==
==9654== Invalid read of size 4
==9654== at 0x43EA96A: lt_dlloader_add (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDC2A: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EA16E: lt_dlpreload_open (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDD30: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4352C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x42339AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x80503D1: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654== Address 0x4a2ebe0 is 32 bytes inside a block of size 36 free'd
==9654== at 0x402265C: free (vg_replace_malloc.c:323)
==9654== by 0x43EDB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4353A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4233974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x805036E: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654==
==9654== Invalid read of size 4
==9654== at 0x43EDC35: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EA16E: lt_dlpreload_open (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDD30: lt_dlinit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4352C03: GetModuleInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EC98: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434EF9C: MagickCoreGenesis (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x42339AE: MagickWandGenesis (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x80503D1: ods_imaging_resize_image (ods-imaging-helpers.c:388)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654== Address 0x4a2ebd4 is 20 bytes inside a block of size 36 free'd
==9654== at 0x402265C: free (vg_replace_malloc.c:323)
==9654== by 0x43EDB2A: lt_dlexit (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4353A46: DestroyModuleList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FA56: DestroyMagickList (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434FAF4: MagickCoreTerminus (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4233974: MagickWandTerminus (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x805036E: ods_imaging_get_image_info (ods-imaging-helpers.c:367)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== by 0x4564E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==9654==
==9654== Invalid read of size 4
==9654== at 0x43EC8F1: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ED43B: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ED884: lt_dlopenadvise (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDA24: lt_dlopen (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4352F60: OpenModule (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434ECB6: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x433E62C: SetImageInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x42CB53E: ReadImage (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x422F07B: MagickReadImage (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x80503ED: ods_imaging_resize_image (ods-imaging-helpers.c:391)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== Address 0x4a2ebdc is 2,484 bytes inside a block of size 16,776 free'd
==9654== at 0x4022B8E: realloc (vg_replace_malloc.c:429)
==9654== by 0x4350313: ResizeMagickMemory (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43503AE: ResizeQuantumMemory (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43A881B: ConcatenateString (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43D1149: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43D2DE5: NewXMLTree (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x42B22A9: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x42B28C4: GetCoderInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4352E69: OpenModule (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434ECB6: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x433E62C: SetImageInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x42CB53E: ReadImage (in /usr/lib/libMagick.so.10.0.9)
==9654==
==9654== Invalid read of size 4
==9654== at 0x43EC8F7: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ED43B: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ED884: lt_dlopenadvise (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDA24: lt_dlopen (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4352F60: OpenModule (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434ECB6: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x433E62C: SetImageInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x42CB53E: ReadImage (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x422F07B: MagickReadImage (in /usr/lib/libWand.so.10.0.9)
==9654== by 0x80503ED: ods_imaging_resize_image (ods-imaging-helpers.c:391)
==9654== by 0x40DDE2E: (within /usr/lib/libglib-2.0.so.0.1600.4)
==9654== by 0x447B4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==9654== Address 0x4a2ebc8 is 2,464 bytes inside a block of size 16,776 free'd
==9654== at 0x4022B8E: realloc (vg_replace_malloc.c:429)
==9654== by 0x4350313: ResizeMagickMemory (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43503AE: ResizeQuantumMemory (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43A881B: ConcatenateString (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43D1149: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43D2DE5: NewXMLTree (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x42B22A9: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x42B28C4: GetCoderInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4352E69: OpenModule (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434ECB6: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x433E62C: SetImageInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x42CB53E: ReadImage (in /usr/lib/libMagick.so.10.0.9)
==9654==
==9654== Jump to the invalid address stated on the next line
==9654== at 0x0: ???
==9654== by 0x43ED43B: (within /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43ED884: lt_dlopenadvise (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x43EDA24: lt_dlopen (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x4352F60: OpenModule (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x434ECB6: GetMagickInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x433E62C: SetImageInfo (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x42CB53E: ReadImage (in /usr/lib/libMagick.so.10.0.9)
==9654== by 0x422F07B: MagickR

General

crash

always

2008-02-11 17:10

2008-06-19 15:05

skirsdeda

high

closed

none

fixed

segfault in ods-bluez

When repeatedly creating Sessions, after some time SEGFAULT occurs in one of ods-bluez functions. This is somehow related to dbus-glib. Probably, memory is not handled the way it should be when making D-Bus calls with call/begin_call/end_call.

wtf.sh (0 KB) 2008-03-02 17:48

hadess

2008-03-02 17:36

Do you have a backtrace of the crash, or a reproducer?

skirsdeda

2008-03-02 17:55

I attach a script that I use to reproduce this bug, which simply repeatedly calls ods-session-test.py with some file. I reject all the files in my mobile (just to make it faster). Then after 50 or so sessions, ods segfaults somewhere in ods-bluez.c.

I had some backtraces, but they are different most of the time. The only thing consistent is that it happens in dbus-glib functions (e.g. end_call).

skirsdeda

2008-03-04 01:18

Sample backtraces at http://pastebin.ca/893725 [^]

heston_james

2008-04-04 23:16

Ok, I'll try and take a look into this issue and see what I can do.

Of this is memory related then it may be a real mofo to track down, I'm not all that great at spotting memory assignment issues.

I'll give this some really thorough testing and see what happens.

Heston

heston_james

2008-04-05 00:09

Ok,

I've downloaded the test script that you attached and run it a few times and can confirm I'm able to reproduce the problem, however, it is giving me very mixed results. :-) :-s :-(

Sometimes when ODS crashes I simply get a 'segmentation fault' returned and the server exits which I'm guessing is the issue you have described above, however, on other occasions I get the following output.

** Message: closing connection
*** glibc detected *** obex-data-server: corrupted double-linked list: 0x08074478 ***
======= Backtrace: =========
/lib/libc.so.6[0xb7d41da5]
/lib/libc.so.6(__libc_malloc+0x8d)[0xb7d42ced]
/usr/lib/libbluetooth.so.2(sdp_extract_attr+0x1c2)[0xb7e38142]
/usr/lib/libbluetooth.so.2(sdp_extract_attr+0x107)[0xb7e38087]
/usr/lib/libbluetooth.so.2(sdp_extract_attr+0x107)[0xb7e38087]
/usr/lib/libbluetooth.so.2(sdp_extract_pdu+0xdc)[0xb7e3840c]
obex-data-server[0x804c794]
/usr/lib/libdbus-glib-1.so.2[0xb7e7f7af]
/usr/lib/libdbus-1.so.3[0xb7e596d1]
/usr/lib/libdbus-1.so.3[0xb7e493f3]
/usr/lib/libdbus-1.so.3(dbus_connection_dispatch+0x99)[0xb7e4af99]
/usr/lib/libdbus-glib-1.so.2[0xb7e7b8fd]
/usr/lib/libglib-2.0.so.0(g_main_context_dispatch+0x178)[0xb7ec67e8]
/usr/lib/libglib-2.0.so.0[0xb7ec9a3e]
/usr/lib/libglib-2.0.so.0(g_main_loop_run+0x1e7)[0xb7ec9dc7]
obex-data-server[0x804d7ce]
/lib/libc.so.6(__libc_start_main+0xe0)[0xb7ceb450]
obex-data-server[0x804b8f1]
======= Memory map: ========
08048000-0805b000 r-xp 00000000 03:01 21177 /usr/local/bin/obex-data-server
0805b000-0805c000 rwxp 00012000 03:01 21177 /usr/local/bin/obex-data-server
0805c000-08096000 rwxp 0805c000 00:00 0 [heap]
b7b00000-b7b21000 rwxp b7b00000 00:00 0
b7b21000-b7c00000 ---p b7b21000 00:00 0
b7c63000-b7c6f000 r-xp 00000000 03:01 92742 /lib/libgcc_s.so.1
b7c6f000-b7c70000 rwxp 0000b000 03:01 92742 /lib/libgcc_s.so.1
b7c70000-b7c77000 r-xs 00000000 03:01 15493 /usr/lib/gconv/gconv-modules.cache
b7c77000-b7c79000 rwxp b7c77000 00:00 0
b7c79000-b7c7b000 r-xp 00000000 03:01 93731 /lib/libdl-2.7.so
b7c7b000-b7c7d000 rwxp 00001000 03:01 93731 /lib/libdl-2.7.so
b7c7d000-b7c91000 r-xp 00000000 03:01 93734 /lib/libnsl-2.7.so
b7c91000-b7c93000 rwxp 00013000 03:01 93734 /lib/libnsl-2.7.so
b7c93000-b7c95000 rwxp b7c93000 00:00 0
b7c95000-b7cbb000 r-xp 00000000 03:01 15974 /usr/lib/libpcre.so.3.12.1
b7cbb000-b7cbc000 rwxp 00025000 03:01 15974 /usr/lib/libpcre.so.3.12.1
b7cbc000-b7cd3000 r-xp 00000000 03:01 92937 /lib/libselinux.so.1
b7cd3000-b7cd5000 rwxp 00016000 03:01 92937 /lib/libselinux.so.1
b7cd5000-b7e1c000 r-xp 00000000 03:01 93728 /lib/libc-2.7.so
b7e1c000-b7e1d000 r-xp 00147000 03:01 93728 /lib/libc-2.7.so
b7e1d000-b7e1f000 rwxp 00148000 03:01 93728 /lib/libc-2.7.so
b7e1f000-b7e23000 rwxp b7e1f000 00:00 0
b7e23000-b7e2a000 r-xp 00000000 03:01 15711 /usr/local/lib/libopenobex.so.1.3.0
b7e2a000-b7e2b000 rwxp 00006000 03:01 15711 /usr/local/lib/libopenobex.so.1.3.0
b7e2b000-b7e3c000 r-xp 00000000 03:01 20032 /usr/lib/libbluetooth.so.2.9.4
b7e3c000-b7e3d000 rwxp 00011000 03:01 20032 /usr/lib/libbluetooth.so.2.9.4
b7e3d000-b7e72000 r-xp 00000000 03:01 20021 /usr/lib/libdbus-1.so.3.4.0
b7e72000-b7e74000 rwxp 00034000 03:01 20021 /usr/lib/libdbus-1.so.3.4.0
b7e74000-b7e8e000 r-xp 00000000 03:01 20472 /usr/lib/libdbus-glib-1.so.2.1.0
b7e8e000-b7e8f000 rwxp 0001a000 03:01 20472 /usr/lib/libdbus-glib-1.so.2.1.0
b7e8f000-b7f3c000 r-xp 00000000 03:01 20034 /usr/lib/libglib-2.0.so.0.1600.1
b7f3c000-b7f3d000 rwxp 000ad000 03:01 20034 /usr/lib/libglib-2.0.so.0.1600.1
b7f3d000-b7f78000 r-xp 00000000 03:01 20037 /usr/lib/libgobject-2.0.so.0.1600.1
b7f78000-b7f79000 rwxp 0003b000 03:01 20037 /usr/lib/libgobject-2.0.so.0.1600.1
b7f79000-b7f7a000 rwxp b7f79000 00:00 0
b7f7e000-b7f7f000 rwxp b7f7e000 00:00 0
b7f7f000-b7f9b000 r-xp 00000000 03:01 93725 /lib/ld-2.7.so
b7f9b000-b7f9d000 rwxp 0001b000 03:01 93725 /lib/ld-2.7.so
bfef3000-bff08000 rw-p bffeb000 00:00 0 [stack]
ffffe000-fffff000 r-xp 00000000 00:00 0 [vdso]
Aborted

Is this is same as what you have been seeing Skirdeda? or have I stumbled accross something else?

Heston.

skirsdeda

2008-04-05 00:13

Yes, that's the same results...

heston_james

2008-04-05 00:21

Ok,

Its getting late and I need some sleep, I'll pick this issue up again tommorow morning and see if I can make any head way.

heston_james

2008-04-05 11:43

Right. I have done some more comprehensive testing this morning to try and narrow down where the problem is and I may possibly have some good news.

I started by testing as before but defining the channel for the remote device manualy like "opp:6", just to see if perhaps it was something in the SDP methods for ods-bluez which was causing the problem, however, the same issues seems to occur even when its not calling bluez to obtain a channel so no help there.

Now, I also built a python script which uses ods, and cycled it using the same style wtf.sh script and this does NOT cause a segfault. I have tested it using the python script and can create 300 or 400 sessions and the ods still doesnt crash and keeps on running exactly as expected.

Could this mean that the segfault is actualy caused by the ods-dbus-test.c file which you've been using to test with?

skirsdeda

2008-06-18 00:21

This might be gone now (as a result of bad memory leaks fixing). Will test more thoroughly tommorow.

skirsdeda

2008-06-18 18:35

fixed in svn rev 1545.

General

crash

always

2008-05-16 18:05

2008-06-18 18:46

cktakahasi

larry

high

closed

none

0.3.1

fixed

Crash when adapter is not available

ODS crashes when the adapter is not available and it receives a CreateBluetoothSession.

How reproduce:
1. start ods
2. start the internal adapter proxy object: $./ods-server-test.py opp "/tmp"
3. remove the adapter or disable if(hciconfig -a hci0 down)
4. create a session: $./ods-dbus-test 00:1C:9A:2B:3C:F2 opp file

heston_james

2008-05-16 19:15

We're planning to change CreateBluetoothSession() so that it allows user to specify which HCI device they with to perform the transfers with, it might be worth addressing this bug along with that feature addition?

Heston

cktakahasi

2008-05-19 16:13

Running ./ods-session-test.py without parameters seems to crash the ODS in the same point: get_remote_service_handles_cb

larry

2008-05-19 21:58

Fixed in Rev 1495.

General

crash

random

2008-03-03 17:26

2008-04-01 16:20

littletux

skirsdeda

high

closed

none

0.3

fixed

obex-data-server sometimes crashes

When I send several (2, 3, 4 or sometimes more) files from my phone to my PC, using Object Push Profile, obex-data-server crashes at the end of one of the transfers.

The destination folder is "~/Téléchargement".

The attached file contains the backtrace.

obex-data-server-bug1.txt (12 KB) 2008-03-03 17:26
obex-data-server-bug2.txt (10 KB) 2008-03-03 17:31

littletux

2008-03-03 17:30

The second file is a different trace I had when trying to reproduce the "corrupted double-linked list" one.

skirsdeda

2008-03-04 01:18

Thanks for report

hadess

2008-03-04 01:27

** (obex-data-server:22892): WARNING **: Session path: /home/ltx-cooker/T?l?chargement

I think obex-data-server is missing a call to setlocale, eg:
setlocale (LC_ALL, "");
first thing in the main

skirsdeda

2008-03-05 22:24

Could you try it again with newest ods from svn?

littletux

2008-03-06 17:33

Fixed.

I could not reproduce any of the two with current svn.

** Message: path: /home/ltx-cooker/Téléchargement
So this was related to localization ?!

Thanks !

skirsdeda

2008-03-06 19:05

Thanks to hadess for an insightful comment.

General

crash

always

2008-03-01 23:49

2008-04-01 16:20

mlind

skirsdeda

high

closed

none

0.3

fixed

Segfault when umounting obexftp device

Forwarding issue https://bugs.launchpad.net/ubuntu/+source/obex-data-server/+bug/196733. [^] Bug report should contain the necessary details.

Not sure if this issue is already reported.

ods-umount-crash.patch (0 KB) 2008-03-02 17:35

skirsdeda

2008-03-02 00:02

You should rebuild obex-data-server with --enable-debug, then launch it manually (./obex-data-server --no-daemon) and post it's ouput. A useful stacktrace would also help (the current one is useless). I'm not sure but this might be the same as 0000046.

mlind

2008-03-02 00:32

Thanks for the response. Updated the original bug report with a debug output and a crash backtrace.

skirsdeda

2008-03-02 00:35

Thanks. Enough information now.

hadess

2008-03-02 17:18

(gdb) bt
#0 obex_event (handle=<value optimized out>, object=0x63e680, mode=<value optimized out>, event=6532800, command=1, response=32) at ods-session.c:335
0000001 0x00000033fc602775 in g_str_equal () from /usr/lib64/libopenobex.so.1
0000002 0x00000033fc6048ed in g_str_equal () from /usr/lib64/libopenobex.so.1
0000003 0x00000033fc6029a0 in g_str_equal () from /usr/lib64/libopenobex.so.1
0000004 0x00000033fc60404f in g_str_equal () from /usr/lib64/libopenobex.so.1
0000005 0x000000000040f1e8 in obex_io_callback (source=<value optimized out>, cond=<value optimized out>, data=0x63f800) at ods-session.c:133
0000006 0x0000003035a3748b in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
0000007 0x0000003035a3ac6d in g_str_equal () from /lib64/libglib-2.0.so.0
#8 0x0000003035a3b19d in g_main_loop_run () from /lib64/libglib-2.0.so.0
#9 0x00000000004064f7 in main (argc=1, argv=0x7fffefaf9d98) at ods-main.c:170

hadess

2008-03-02 17:21

==8261== Invalid read of size 8
==8261== at 0x40F537: obex_event (ods-session.c:335)
==8261== by 0x33FC602774: (within /usr/lib64/libopenobex.so.1.3.0)
==8261== by 0x33FC6048EC: (within /usr/lib64/libopenobex.so.1.3.0)
==8261== by 0x33FC60299F: (within /usr/lib64/libopenobex.so.1.3.0)
==8261== by 0x33FC60404E: (within /usr/lib64/libopenobex.so.1.3.0)
==8261== by 0x40F1E7: obex_io_callback (ods-session.c:133)
==8261== by 0x3035A3748A: g_main_context_dispatch (in /lib64/libglib-2.0.so.0.1505.0)
==8261== by 0x3035A3AC6C: (within /lib64/libglib-2.0.so.0.1505.0)
==8261== by 0x3035A3B19C: g_main_loop_run (in /lib64/libglib-2.0.so.0.1505.0)
==8261== by 0x4064F6: main (ods-main.c:170)
==8261== Address 0xAAAAAAAAAAAAAB0A is not stack'd, malloc'd or (recently) free'd
==8261==
==8261== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==8261== General Protection Fault
==8261== at 0x40F537: obex_event (ods-session.c:335)
==8261== by 0x33FC602774: (within /usr/lib64/libopenobex.so.1.3.0)
==8261== by 0x33FC6048EC: (within /usr/lib64/libopenobex.so.1.3.0)
==8261== by 0x33FC60299F: (within /usr/lib64/libopenobex.so.1.3.0)
==8261== by 0x33FC60404E: (within /usr/lib64/libopenobex.so.1.3.0)
==8261== by 0x40F1E7: obex_io_callback (ods-session.c:133)
==8261== by 0x3035A3748A: g_main_context_dispatch (in /lib64/libglib-2.0.so.0.1505.0)
==8261== by 0x3035A3AC6C: (within /lib64/libglib-2.0.so.0.1505.0)
==8261== by 0x3035A3B19C: g_main_loop_run (in /lib64/libglib-2.0.so.0.1505.0)
==8261== by 0x4064F6: main (ods-main.c:170)

skirsdeda

2008-03-02 17:25

This is different from 0000046 and I already know how to fix this one (unlike 0000046 :D). Thanks for info.

hadess

2008-03-02 17:35

Patch attached :)

skirsdeda

2008-03-02 18:00

Fixed in svn. Thanks for patch.

mlind

2008-03-02 21:24

With the applied patch I'm currently unable to establish connection at all. It seems that obex_io_callback() exits early returning FALSE everytime now.

** Message: obex-data-server 0.3
** Message: Using Session bus
** Message: Parsed[0]: ftp, Parsed[1]: (null)
** Message: Connecting to 00:15:2A:26:16:8E using channel 10
** Message: Connect in progress
** Message: Connect complete
** Message: Session created by: :1.79

.. and then nothing else.

Without the patch I can establish connection to a device, but crash occurs during umount. Should I open a separate issue for this?

hadess

2008-03-02 21:29

Bleh. Probably a side-effect of my patch indeed :(

skirsdeda

2008-03-02 23:57

Yeah. I suspected this, but were too lazy to test :) Anyway, this patch is kind of workaround rather than fix. I'm gonna do a proper one when I have some time.

skirsdeda

2008-03-05 22:14

Could anyone test again with with newest ods from svn?

hadess

2008-03-05 23:22

$ ./obex-data-server --no-daemon
** Message: obex-data-server 0.3
** Message: Using Session bus
** Message: Parsed[0]: ftp, Parsed[1]: (null)
** Message: Connecting to 00:12:D2:79:B7:33 using channel 10
** Message: Connect in progress
** Message: Connect complete
** Message: Session created by: :1.140
** Message: io callback
** Message: event: 3

** (obex-data-server:9882): WARNING **: DBUS NAME REMOVED: :1.140

** (obex-data-server:9882): WARNING **: Finalizing session
** Message: attempting to close session
** Message: session cancelled
** Message: Sending CMD_DISCONNECT
** Message: io callback
** Message: event: 3
** Message: session closed
** Message: Removing listened DBUS name :1.140 (object: /org/openobex/session0)
** Message: Removed from listened DBUS names list
** Message: closing connection
Segmentation fault (core dumped)

Same problem I'm afraid.

mlind

2008-03-05 23:29

I just tried with current svn trunk, revision 1390, but the problem remains.

Here's what I get with gvfs 0.1.11 and obex-data-server trunk:
$ obex-data-server --no-daemon &
** Message: obex-data-server 0.3
** Message: Using Session bus

$ gvfs-mount obex://[xx:xx:yy:yy:zz:zz]/ [^]
** Message: Parsed[0]: ftp, Parsed[1]: (null)
** Message: Connecting to xx:xx:yy:yy:zz:zz using channel 10
** Message: Connect in progress
** Message: Connect complete
** Message: Session created by: :1.298
** Message: io callback
** Message: event: 3

$ gvfs-mount -u obex://[xx:xx:yy:yy:zz:zz]/ [^]
** (obex-data-server:21080): WARNING **: DBUS NAME REMOVED: :1.298

** (obex-data-server:21080): WARNING **: Finalizing session
** Message: attempting to close session
** Message: session cancelled
** Message: Sending CMD_DISCONNECT
** Message: io callback
** Message: event: 3
** Message: session closed
** Message: Removing listened DBUS name :1.298 (object: /org/openobex/session0)
** Message: Removed from listened DBUS names list
** Message: closing connection

[2]+ Segmentation fault (core dumped) obex-data-server --no-daemon

skirsdeda

2008-03-06 19:24

I need to know whether io_callback function (ods-session.c) is called AFTER ods_session_finalize (ods-session.c).

mlind

2008-03-06 19:47

I went the execution through with a debugger. When umount happens, the order is

obex_io_callback
obex_request_done
ods_session_finalize

after this the execution continues in obex_request_done and segfault happens. no obex_io_callback is called anymore.

I tried to find the cause why session->priv->dbus_context pointer is invalid in obex_request_done when the case is OBEX_CMD_DISCONNECT, but didn't get any wiser.

If you can give any hints or pointers where the problem might be, I'll provide the debug information.

skirsdeda

2008-03-06 20:18

The problem is that nothing should be done in session after ods_session_finalize is called because it frees all resources (including session->priv->dbus_context).

Could you also see when obex_event is called?

I suppose it's like this:
obex_io_callback
obex_event
obex_request_done
ods_session_finalize
obex_event
obex_request_done

Is it?

hadess

2008-03-06 20:24

Getting a backtrace for that last obex_request_done() might be helpful.

mlind

2008-03-06 22:06

This seems to be the execution sequence:
obex_io_callback
obex_event
obex_request_done
ods_session_finalize
obex_request_done

I'm including the gdb session if it makes any sense. Breakpoints are enabled before umounting the device. Backtrace you asked should be included.

(gdb) break obex_io_callback
(gdb) break obex_event
(gdb) break obex_request_done
(gdb) break ods_session_finalize
(gdb) run
Starting program: /usr/bin/obex-data-server --no-daemon
** Message: obex-data-server 0.3
** Message: Using Session bus
** Message: Parsed[0]: ftp, Parsed[1]: (null)
** Message: Connecting to 00:15:2A:26:16:8E using channel 10
** Message: Connect in progress
** Message: Connect complete
** Message: Session created by: :1.245

Breakpoint 1, obex_io_callback (io_channel=0x80847a0, cond=G_IO_IN, data=0x8086948) at ods-session.c:110
110 GError *error = NULL;
(gdb) disable
(gdb) cont
Continuing.
** Message: io callback
** Message: event: 3
** Message: LOCK
** Message: io callback
** Message: event: 0
** Message: io callback
** Message: io callback
** Message: io callback
** Message: event: 9
** Message: There is some data
** Message: Writing to buf
** Message: event: 9
** Message: event: 3
** Message: UNLOCK
** Message: LOCK
** Message: io callback
** Message: event: 3
** Message: UNLOCK
** Message: Got response: Forbidden
** Message: UNLOCK
** Message: LOCK
** Message: io callback
** Message: event: 3
** Message: UNLOCK
** Message: Got response: Forbidden
** Message: UNLOCK
** Message: LOCK
** Message: io callback
** Message: event: 3
** Message: UNLOCK
** Message: Got response: Forbidden
** Message: UNLOCK
** Message: LOCK
** Message: io callback
** Message: event: 3
** Message: UNLOCK
** Message: Got response: Forbidden
** Message: UNLOCK
** Message: LOCK
** Message: io callback
** Message: event: 3
** Message: UNLOCK
** Message: Got response: Forbidden
** Message: UNLOCK
** Message: LOCK
** Message: io callback
** Message: event: 3
** Message: UNLOCK
** Message: Got response: Forbidden
** Message: UNLOCK
** Message: LOCK
** Message: io callback
** Message: event: 3
** Message: UNLOCK
** Message: Got response: Forbidden
** Message: UNLOCK
** Message: LOCK
** Message: io callback
** Message: event: 3
** Message: UNLOCK
** Message: Got response: Forbidden
** Message: UNLOCK
** Message: LOCK
** Message: io callback
** Message: event: 3
** Message: UNLOCK
** Message: Got response: Forbidden
** Message: UNLOCK
** Message: LOCK
** Message: io callback
** Message: io callback
** Message: io callback
** Message: io callback
** Message: io callback
** Message: io callback
** Message: event: 9
** Message: There is some data
** Message: Writing to buf
** Message: event: 9
** Message: event: 3
** Message: UNLOCK

Program received signal SIGINT, Interrupt.
0xb7f72410 in __kernel_vsyscall ()
(gdb) enable
(gdb) cont
Continuing.

** (obex-data-server:31552): WARNING **: DBUS NAME REMOVED: :1.245

** (obex-data-server:31552): WARNING **: Finalizing session
** Message: attempting to close session
** Message: session cancelled
** Message: Sending CMD_DISCONNECT

Breakpoint 1, obex_io_callback (io_channel=0x80847a0, cond=G_IO_IN, data=0x8086948) at ods-session.c:110
110 GError *error = NULL;
(gdb) cont
Continuing.
** Message: io callback

Breakpoint 2, obex_event (handle=0x8086948, object=0x8080ff8, mode=0, event=3, command=1, response=32) at ods-session.c:354
354 session = ODS_SESSION (OBEX_GetUserData (handle));
(gdb)
Continuing.
** Message: event: 3

Breakpoint 3, obex_request_done (session=0x8086c08, object=0x8080ff8, command=1, response=32) at ods-session.c:212
212 GError *error = NULL;
(gdb) bt
#0 obex_request_done (session=0x8086c08, object=0x8080ff8, command=1, response=32) at ods-session.c:212
0000001 0x080583d0 in obex_event (handle=0x8086948, object=0x8080ff8, mode=0, event=3, command=1, response=32) at ods-session.c:372
0000002 0xb7e097c1 in obex_deliver_event () from /usr/lib/libopenobex.so.1
0000003 0xb7e0bf48 in obex_client () from /usr/lib/libopenobex.so.1
0000004 0xb7e09a4e in obex_data_indication () from /usr/lib/libopenobex.so.1
0000005 0xb7e0b4ac in obex_transport_handle_input () from /usr/lib/libopenobex.so.1
0000006 0xb7e0916d in OBEX_HandleInput () from /usr/lib/libopenobex.so.1
0000007 0x080578fa in obex_io_callback (io_channel=0x80847a0, cond=G_IO_IN, data=0x8086948) at ods-session.c:133
#8 0xb7edf33d in ?? () from /usr/lib/libglib-2.0.so.0
#9 0x080847a0 in ?? ()
0000010 0x00000001 in ?? ()
0000011 0x08086948 in ?? ()
0000012 0xb7f21248 in ?? () from /usr/lib/libglib-2.0.so.0
0000013 0xbfa42b5c in ?? ()
0000014 0x08086190 in ?? ()
0000015 0xbfa42b78 in ?? ()
0000016 0xb7eaad86 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
Backtrace stopped: frame did not save the PC
(gdb) cont
Continuing.
** Message: session closed
** Message: Removing listened DBUS name :1.245 (object: /org/openobex/session0)
** Message: Removed from listened DBUS names list

Breakpoint 4, ods_session_finalize (object=0x8086c08) at ods-session.c:727
727 g_return_if_fail (object != NULL);
(gdb)
Continuing.
** Message: closing connection

Program received signal SIGSEGV, Segmentation fault.
0x08058188 in obex_request_done (session=0x8086c08, object=0x8080ff8, command=1, response=32) at ods-session.c:335
335 if (session->priv->dbus_context) {
(gdb)

skirsdeda

2008-03-06 22:48

I redesigned obex_request_done a bit. Please test with ods from svn.

mlind

2008-03-06 23:05

Good job, r1393 from svn fixes this issue, thanks!

skirsdeda

2008-03-06 23:06

Thanks for your cooperation, you've been very helpful :)

433

General

major

sometimes

2010-04-18 11:24

2010-04-19 00:07

crevette

normal

new

none

0.4.5

open

obex-data-server crashed with SIGSEGV in g_main_context_dispatch() after transfer

There is a crasher that make o-d-s crash after a transfer, the stacktrace is not complete because some glib symbols were missing, I'm waiting a better one from reporters.

.
Thread 1 (process 1421):
#0 obex_io_callback (io_channel=0x938c348, cond=<value optimized out>,
    data=0x938e978) at src/ods-session.c:193
    session = (OdsSession *) 0x0
    error = (GError *) 0x0
    ret = <value optimized out>
    __FUNCTION__ = "obex_io_callback"
0000001 0x00299e6b in ?? () from /lib/libglib-2.0.so.0
No symbol table info available.
0000002 0x002555e5 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
No symbol table info available.
0000003 0x002592d8 in ?? () from /lib/libglib-2.0.so.0
No symbol table info available.
0000004 0x00259817 in g_main_loop_run () from /lib/libglib-2.0.so.0
No symbol table info available.
0000005 0x08051b5d in main (argc=2, argv=0xbf91e594) at src/ods-main.c:195
    session_connection = <value optimized out>
    error = (GError *) 0x0
    context = <value optimized out>
    sa = {__sigaction_handler = {sa_handler = 0x80515f0 <sig_term>,
    sa_sigaction = 0x80515f0 <sig_term>}, sa_mask = {__val = {
      0 <repeats 32 times>}}, sa_flags = 0, sa_restorer = 0}
    no_daemon = 1
    system_bus = 0
    show_version = 0
    log = 0
    debug = 0
    options = {{long_name = 0x8064775 "no-daemon", short_name = 110 'n',
    flags = 0, arg = G_OPTION_ARG_NONE, arg_data = 0xbf91e4c8,
    description = 0x806477f "Do not daemonize", arg_description = 0x0}, {
    long_name = 0x8064790 "system-bus", short_name = 115 's', flags = 0,
    arg = G_OPTION_ARG_NONE, arg_data = 0xbf91e4c4,
    description = 0x8064888 "Use system bus instead of the default session bus", arg_description = 0x0}, {long_name = 0x80647b2 "log", short_name = 108 'l',
    flags = 0, arg = G_OPTION_ARG_NONE, arg_data = 0xbf91e4bc,
    description = 0x806479b "Log all messages to syslog",
    arg_description = 0x0}, {long_name = 0x80647b6 "debug",
    short_name = 100 'd', flags = 0, arg = G_OPTION_ARG_NONE,
    arg_data = 0xbf91e4b8,
    description = 0x80647bc "Enable debugging messages",
    arg_description = 0x0}, {long_name = 0x80647d6 "version",
    short_name = 118 'v', flags = 0, arg = G_OPTION_ARG_NONE,
    arg_data = 0xbf91e4c0,
    description = 0x80648bc "Show version of obex-data-server and exit immediately", arg_description = 0x0}, {long_name = 0x0, short_name = 0 '\0',
    flags = 0, arg = G_OPTION_ARG_NONE, arg_data = 0x0, description = 0x0,
    arg_description = 0x0}}

Downstream bug:
https://bugs.launchpad.net/ubuntu/+source/obex-data-server/+bug/559876 [^]

skirsdeda

2010-04-19 00:07

This is probably fixed in svn already. If someone can test with svn version, it would be great but there is high probability that it's already fixed. I just need to do a new release (probably in the beginning of may).

351

General

major

always

2010-02-03 16:24

2010-02-03 16:25

justinas

normal

assigned

none

open

Reikia momentinio nuotrauku ikelimo image plugin'ui

Reikia kad prie ten kur galima irasyti img URL butu galimybe tiesiai nusiusti nuotrauka i serveri ir kad laukelyje atsirastu URL be browsinimo

246

General

major

always

2009-12-14 15:45

2010-01-09 10:31

live4love

skirsdeda

normal

feedback

none

0.4.4

reopened

obex-data-server can not receive file through bluetooth with size large than 512 bytes

When I send a file with size >= 512 from phone to PC through bluetooth, obex-data-server will fail to receive it.

bluetooth-applet show following logging when it start.
** Message: adding killswitch idx 1 state 1
** Message: Reading of RFKILL events failed
** Message: killswitch 1 is 1
** Message: killswitches state 1
** (bluetooth-applet:3529): DEBUG: Unhandled UUID 00005005-0000-1000-8000-0002ee000001 (0x5005)
** Message: killswitch 1 is 1
** Message: killswitches state 1

obex-data-server console displays while transtering:

** Message: server socket created
** Message: Server created by: :1.40

** (obex-data-server:3465): WARNING **: Server path: /mypath
** Message: Client connecting

** (obex-data-server:3465): WARNING **: Session path: /mypath
** Message: Bluetooth address: 00:13:70:22:12:42
** Message: Creating server session
** Message: io callback
** Message: event: 1
** Message: event: 2
** Message: CMD_CONNECT requested
** Message: Version: 0x10. Flags: 0x00 OBEX packet length: 4000

** Message: Resizing stream chunks to 3800

** Message: event: 3
** Message: io callback
** Message: event: 1
** Message: event: 11
** Message: CMD_PUT requested at REQCHECK
** Message: header: 1
** Message: HDR_NAME: tbig
** Message: header: 195
** Message: HDR_LENGTH: 512
** Message: header: 66
** Message: ret=-1
** Message: event: 3
** Message: io callback
** Message: server session closed
** Message: closing connection

It is tested on
ubuntu 9.10 32bit (kernel 2.6.31-16)
bluetooth dongle BCM2035
obex-data-server 0.4.4-2build1(installed by default in ubuntu 9.10)

Phone: Nokia 3230

It is okay to receive file with size < 512bytes from phone.(See attachment)
It is okay to send file from PC to phone, with any size.
It is okay to receive file from phone through obexpushd instead of obex-data-server, with any size.
It is okay to send/receive file using obex-data-server with another Phone SonyEricsson 700.

I think it should not be an issue on the phone, because I test it works anywhere else.

obex_success (1 KB) 2009-12-14 15:45

skirsdeda

2009-12-14 17:16

It seems that your phone sends TYPE header which obex-data-server cosiders invalid. I will try to put more debugging info in this case so that I could actually see why this header is considered to be invalid. I'll let you know when I have an improved version.

skirsdeda

2010-01-03 19:08

Could you please try the newest code from svn? You could do this in console:
svn co svn://muiline.com/obex-data-server/trunk [^] obex-data-server
cd obex-data-server
./autogen.sh
make
killall obex-data-server
./src/obex-data-server --no-daemon

Then try sending again and send me obex-data-server output (even if it works, I want to see how that invalid header looks like). I really have no way of testing this so your cooperation would be much appreciated :)

live4love

2010-01-09 09:59

skirsdeda, thanks for your work. The svn version is okay to send file with any size.
A limitation is, after obex-data-server(svn version) started, I have to restart bluetooth before any transferring.

Logging from obex-data-server:

1.start obex-data-server(svn)

obex-data-server 0.4.6svn
Using Session bus

2.restart bluetooth. Run /etc/init.d/bluetooth stop, then start.

server socket created
Server created by: :1.23
**Warning: Server path: /mypath

3. transfer bigfile - success

Client connecting
**Warning: Session path: /mypath
Bluetooth address: 00:13:70:22:12:42
Creating server session
Used MTUs: RX=32767, TX=32767
io callback
CMD_CONNECT requested
Version: 0x10. Flags: 0x00 OBEX packet length: 4000
Resizing stream chunks to 3800
io callback
CMD_PUT requested at REQCHECK
header: 1
HDR_NAME: bigfile
header: 195
HDR_LENGTH: 612
header: 66
HDR_TYPE invalid: text/plain�K�
header: 68
HDR_TIME
path: /mypath
ret=0
TransferStarted emitted at obex_request_put
Suspending request
LOCK ods_server_session_accept
UNLOCK ods_server_session_accept
Suspend result: 1
io callback
There is some data
CMD_PUT requested
io callback
server session closed
closing connection

4. transfer more large file (mp3) - success

Client connecting
**Warning: Session path: /mypath
Bluetooth address: 00:13:70:22:12:42
Creating server session
Used MTUs: RX=32767, TX=32767
io callback
CMD_CONNECT requested
Version: 0x10. Flags: 0x00 OBEX packet length: 4000
Resizing stream chunks to 3800
io callback
CMD_PUT requested at REQCHECK
header: 1
HDR_NAME: QUEEN2.MP3
header: 195
HDR_LENGTH: 940826
header: 66
HDR_TYPE invalid: audio/mpeg�K�
header: 68
HDR_TIME
path: /mypath
ret=0
TransferStarted emitted at obex_request_put
Suspending request
LOCK ods_server_session_accept
UNLOCK ods_server_session_accept
Suspend result: 1
io callback
io callback
io callback
io callback
io callback
io callback

...

There is some data
io callback
io callback
io callback
io callback
There is some data
CMD_PUT requested
io callback
server session closed
closing connection

5. transfer small file - success

Client connecting
**Warning: Session path: /mypath
Bluetooth address: 00:13:70:22:12:42
Creating server session
Used MTUs: RX=32767, TX=32767
io callback
CMD_CONNECT requested
Version: 0x10. Flags: 0x00 OBEX packet length: 4000
Resizing stream chunks to 3800
io callback
CMD_PUT requested at REQCHECK
header: 1
HDR_NAME: smallfile
header: 195
HDR_LENGTH: 511
header: 68
HDR_TIME
path: /mypath
ret=0
TransferStarted emitted at obex_request_put
Suspending request
LOCK ods_server_session_accept
UNLOCK ods_server_session_accept
Suspend result: 1
io callback
There is some data
CMD_PUT requested
io callback
server session closed
closing connection

Notes:
For large file, HDR_TYPE shows garbled text. But the transferring can finish without any exception.I wonder the garbled text is generated by my Nokia phone in Chinese.

For step 2: I have to restart bluetooth before any transferring, otherwise connections from phone to PC will always fail, sometimes connection succeed but transferring fail(even for small file, see following logging).

Client connecting
**Warning: Session path: /mypath
Bluetooth address: 00:13:70:22:12:42
Creating server session
Used MTUs: RX=32767, TX=32767
io callback
CMD_CONNECT requested
Version: 0x10. Flags: 0x00 OBEX packet length: 4000
Resizing stream chunks to 3800
io callback
CMD_PUT requested at REQCHECK
header: 1
HDR_NAME: smallfile
header: 195
HDR_LENGTH: 511
header: 68
HDR_TIME
path: /mypath
ret=0
TransferStarted emitted at obex_request_put
Suspending request
Suspend timeout (15s), rejecting incoming file
Suspend result: -1
io callback
server session closed
closing connection

live4love

2010-01-09 10:31

Another logging from obex-data-server(svn version) for SonyEricssion phone, succeed to transfer a big file:

Client connecting
**Warning: Session path: /mypath
Bluetooth address: 00:18:13:B4:B0:EC
Creating server session
Used MTUs: RX=32767, TX=32767
io callback
CMD_CONNECT requested
Version: 0x10. Flags: 0x00 OBEX packet length: 4096
Resizing stream chunks to 3896
io callback
io callback
There is some data
Writing to buf
CMD_PUT requested at REQCHECK
header: 1
HDR_NAME: bigfile.
header: 195
HDR_LENGTH: 612
path: /mypath
ret=0
TransferStarted emitted at obex_request_put
Suspending request
LOCK ods_server_session_accept
UNLOCK ods_server_session_accept
Suspend result: 1
io callback
CMD_PUT requested
io callback
server session closed
closing connection

242

General

major

always

2009-12-09 15:53

2009-12-11 16:11

cgarcia

normal

new

none

0.4.5

open

delete not compliant with obex specification

I have debugged a communication problem (with a own-developed client) until finding that the server does not follows the OBEX specification for deleting files, potentially causing data transmissions to be incorrectly handled as if they were file deletions. Since I have previously used the same client and never found a problem (both with other linux and Windows/Mac obex servers) I suspect that this may cause incompatibilities with many other clients out there, depending on their design.

I detected the problem in the 0.4.4 version ship with ubuntu karmic, but it is still present in the subversion trunk (I have not tested previous versions). The problem is due to the following: the function ods_obex_srv_put() in ods-obex.c considers that the PUT request is a file deletion (is_delete = TRUE) unless the client has previously sent any of the following headers: OBEX_HDR_BODY, OBEX_HDR_TYPE or OBEX_HDR_LENGTH. Since my client do not sends the type nor the length (unknown at transmission start) and it does not sends a body header in the first packet, obex-data-server incorrectly interpretes this as a file deletion and aborts the data transmission.

The OBEX specification (at least 1.2) says about delete:

"A PUT operation with NO Body or End-of-Body headers whatsoever should be treated as a delete request. Similarly, a PUT operation with an empty End-of-Body header requests the recipient to create an empty object. This definition may not make sense or apply to every implementation (in other words devices are not required to support delete operations or empty objects)."

That is, it mentions the complete "PUT operation" (not the first packet) and includes a "whatsoever" word. In another section, the specification is even more clear about this fact:

"A PUT request consists of one or more request packets, the last of which has the Final bit set in the opcode. The implementer may choose whether to include an object Body header in the first packet, or wait until the response to the initial packet is received before sending any object body chunks."

I was one of those implementers choosing not to send a body header in the first packet. My current workarround in order to improve the compatibility with previous obex-data-server versions it will be to include a OBEX_HDR_TYPE.

skirsdeda

2009-12-11 16:11

I could try rewriting code so that decision whether file should be deleted would be made at the end of PUT request. This would definitely be a correct way to handle this.

233

FTP

major

random

2009-12-03 21:19

2009-12-04 13:06

walmis

normal

new

none

0.4.5

open

File corruption when transferring with nautilus

Sometimes when transferring multiple files with nautilus some files come out corrupted. In the case of images, the bottom part is cut off, if multiple images are corrupted, those images are cut off at the exactly same place.

Can't seem to reproduce when transferring files one by one, only when bunch of files are selected and copied.

Nautilus: 2.26
gvfs: 1.4.1
ods: 0.4.5

http://ubuntuforums.org/showthread.php?t=1330074 [^]

out.log (217 KB) 2009-12-03 21:19
Atvaizd058.jpg (160 KB) 2009-12-03 21:20

skirsdeda

2009-12-04 13:06

Unrelated bug from log: modification time is not set correctly after receiving file.

227

General

major

always

2009-11-22 22:31

2009-11-26 18:49

drgr33n

normal

new

none

0.4.5

open

Failing to compile on my machine.

First error was stdlib.h was not included in src/ods-common.c.

My next error is im getting undefined reference to `OBEX_FindInterfaces' in ods-obex.c.

I'm not sure how to fix this but I can see that OBEX_FindInterfaces is declared in obex.h.

Here's the error output ..

src/ods-obex.o: In function `ods_obex_setup_usbtransport':
/root/software/build/bluez/obex-data-server/src/ods-obex.c:408: undefined reference to `OBEX_FindInterfaces'
collect2: ld returned 1 exit status

skirsdeda

2009-11-26 18:49

I need some more info for this. You could try attaching here output from "./configure --disable-silent-rules" and "make".

155

OPP

major

always

2009-01-29 07:27

2009-10-21 20:13

skirsdeda

normal

closed

none

0.4.2

fixed

ODS does not response the cancel request if the opponent is in a suspended state

Here is my problamatic situation.

I tried to send a file using OPP to other phone. When the request is reached to the remote phone, it went into a suspended mode waiting for a user's determination whether to accept the file. At this moment I cancelled the file transmission via "cancel" dbus call to ODS.

But at this moment the opponent phone seems that it does not send any response to the ODS. Therefore ODS can not perform the cancel procedure cause it does not get to the "ods_obex_writestream". ODS just waits for the non-answering response.

This situation happens when the remote target is a Samsung phone with its secure mode set on.

In short, my question is how to cancel the ongoing request even the opponent does not send a response, i.e., ODS does not get an "OBEX_EV_STREAMEMPTY" signal.

I attach a ODS log below indicating the cancel call timing.

Thanks in advance.

** Message: LOCK
** Message: event: 8
** Message: obex_writestream
** Message: writestream from File: 9
** Message: event: 8
** Message: obex_writestream
** Message: writestream from File: 9
** Message: event: 0

** (obex-data-server:923): WARNING **: PROGRESS: 8132
** Message: UNLOCK

>> Here ods_session_cancel is called <<

** Message: LOCK

>> But no progress <<

skirsdeda

2009-01-29 13:17

This is a known bug. The problem is that when remote device is in suspended state (asks user to accept/reject), it usually does not listen to incoming data. Therefore, even if ods sends ABORT command, remote device does not respond. The only way to fix this is by implementing a timeout system in ods. When Cancel is called, a timeout would start and if remote device does not respond in the specified time frame, ods would just drop connection and emit ErrorOccurred signal with Timeout error.

2009-01-30 01:48

Haha, exactly the same bug :) I confirmed.

skirsdeda

2009-08-22 21:10

should be fixed in svn

162

General

major

always

2009-05-29 12:07

2009-10-19 20:13

maximi89

normal

closed

none

0.4.4

no change required

obex-data-server can't respond to petitions of bluetooth devices

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=530826 [^]

when a device try to contact to a computer with obex-data-server running, nothing happens, because this don't don't responde nothing, but sending files works good... using bluez-gnome like say the link

maximi89@Maximiliano:~$ sudo hcidump
[sudo] password for maximi89:
HCI sniffer - Bluetooth packet analyzer ver 1.42
device: hci0 snap_len: 1028 filter: 0xffffffff
> HCI Event: Connect Request (0x04) plen 10
< HCI Command: Accept Connection Request (0x01|0x0009) plen 7
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Role Change (0x12) plen 8
> HCI Event: Connect Complete (0x03) plen 11
< HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
> HCI Event: Max Slots Change (0x1b) plen 3
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Connection Packet Type Changed (0x1d) plen 5
< HCI Command: Remote Name Request (0x01|0x0019) plen 10
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Read Remote Supported Features (0x0b) plen 11
> HCI Event: Remote Name Req Complete (0x07) plen 255
> ACL data: handle 1 flags 0x02 dlen 12
    L2CAP(s): Connect req: psm 1 scid 0x0040
< ACL data: handle 1 flags 0x02 dlen 16
    L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0040 result 1 status 0
      Connection pending - No futher information available
< ACL data: handle 1 flags 0x02 dlen 10
    L2CAP(s): Info req: type 2
> HCI Event: Number of Completed Packets (0x13) plen 5
> HCI Event: Number of Completed Packets (0x13) plen 5
> ACL data: handle 1 flags 0x02 dlen 16
    L2CAP(s): Info rsp: type 2 result 0
      Extended feature mask 0x0000
< ACL data: handle 1 flags 0x02 dlen 16
    L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0040 result 0 status 0
      Connection successful
> HCI Event: Number of Completed Packets (0x13) plen 5
> ACL data: handle 1 flags 0x02 dlen 16
    L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
      MTU 1024
< ACL data: handle 1 flags 0x02 dlen 18
    L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 4
      MTU 1024
< ACL data: handle 1 flags 0x02 dlen 12
    L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 0
> HCI Event: Number of Completed Packets (0x13) plen 5
> HCI Event: Number of Completed Packets (0x13) plen 5
> ACL data: handle 1 flags 0x02 dlen 14
    L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
      Success
> ACL data: handle 1 flags 0x02 dlen 34
    L2CAP(d): cid 0x0040 len 30 [psm 1]
        SDP SSA Req: tid 0x1 len 0x19
          pat uuid-16 0x1105 (OBEXObjPush)
          max 128
          aid(s) 0x0000 (SrvRecHndl) 0x0001 (SrvClassIDList) 0x0002 (SrvRecState) 0x0006 (LangBaseAttrIDList) 0x0009 (BTProfileDescList)
          cont 00
< ACL data: handle 1 flags 0x02 dlen 14
    L2CAP(d): cid 0x0040 len 10 [psm 1]
        SDP SSA Rsp: tid 0x1 len 0x5
          count 2
          cont 00
> HCI Event: Number of Completed Packets (0x13) plen 5
> ACL data: handle 1 flags 0x02 dlen 12
    L2CAP(s): Disconn req: dcid 0x0040 scid 0x0040
< ACL data: handle 1 flags 0x02 dlen 12
    L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x0040
> HCI Event: Number of Completed Packets (0x13) plen 5
> HCI Event: Disconn Complete (0x05) plen 4

maximi89@Maximiliano:~$ obex-data-server --no-daemon
** Message: obex-data-server 0.4.4
** Message: Using Session bus

i try with gnome-obex-server and works great.

skirsdeda

2009-05-29 14:56

From original bug:
>> I was trying gnome-obex-server and gnome-obex-send of gnome-bluetooth
>> works very well, but obex-data-server 0.4.4-1, is called by
>> bluetooth-applet, if you send a file from this program, and you cancel
>> the transfers, the
>> connection still alive and if you accept of phone recently in that
>> moment the phone understand the conecction was closed, also if you
>> send from phone, this fails with no conecction detected, because
>> obex-data-server don't understand nothing when the conecction coming,

skirsdeda

2009-05-29 14:57

Sorry, but I can't really understand what is the problem from neither of these descriptions. Could you try explaining all the steps needed to reproduce this in a clear understandable way.

maximi89

2009-05-29 22:43

sorry, i'm not english native, but that description say in others words:
gnome-obex-server works, but have problems for cancel coming files.

and obex-data-server don't do nothing, i use "bluez-hcidump" for see what happen, and from all devices i have, a Motorola L6i and from Samsung YP-T10 all fails with "impossible to connect".
When i send files using obex-data-server this works well, so the problem is only receiving files from Bluetooth, if you need any thing more, tell me, i can send you all you need if you tell me how.

Greetings!

maximi89

2009-05-29 22:45

may be that are relationed with this:

http://git.kernel.org/?p=linux/kernel/git/holtmann/bluetooth-testing.git;a=commitdiff;h=aa3972ded9bbc34642693ea4bc262b9eb7f8fef3 [^]

skirsdeda

2009-05-29 22:52

Yes, that is possible. But anyway, if ods doesn't work while gnome-obex-server works, it's strange.

maximi89

2009-05-31 11:58

Filippo from Debian Bug Track discovered

maximi89@Maximiliano:~/obex-data-server-0.4.4$ python test/ods-server-test.py opp /tmp
Server object: /org/openobex/server0
Started
Session created: /org/openobex/serversession0
Session Bluetooth address: 00:XX:XX:XX:X3:2X
>>/org/openobex/serversession0<< Transfer started (blink 182 - the rock show.mp3, /tmp/blink 182 - the rock show.mp3, 2688313)
>>/org/openobex/serversession0<< All transfer info:
>>/org/openobex/serversession0<< -- OBEXCommand = PUT
>>/org/openobex/serversession0<< -- Size = 2688313
>>/org/openobex/serversession0<< -- Type = audio/mp3
>>/org/openobex/serversession0<< -- LocalPath = /tmp/blink 182 - the rock show.mp3
>>/org/openobex/serversession0<< -- RemoteFilename = blink 182 - the rock show.mp3
>>/org/openobex/serversession0<< Progress: 0 %
>>/org/openobex/serversession0<< Progress: 0 %
>>/org/openobex/serversession0<< Progress: 0 %
>>/org/openobex/serversession0<< Progress: 0 %

Maximiliano:/home/maximi89# udevadm monitor
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent
KERNEL[1243760130.024623] add /devices/pci0000:00/0000:00:02.0/usb2/2-2/2-2:1.0/bluetooth/hci0/hci0:1 (bluetooth)
UDEV [1243760130.025408] add /devices/pci0000:00/0000:00:02.0/usb2/2-2/2-2:1.0/bluetooth/hci0/hci0:1 (bluetooth)
KERNEL[1243760134.102009] remove /devices/pci0000:00/0000:00:02.0/usb2/2-2/2-2:1.0/bluetooth/hci0/hci0:1 (bluetooth)
UDEV [1243760134.102761] remove /devices/pci0000:00/0000:00:02.0/usb2/2-2/2-2:1.0/bluetooth/hci0/hci0:1 (bluetooth)

hcidump
http://pastebin.ca/1442004 [^]

skirsdeda

2009-05-31 16:03

It just doesn't look like something caused by ods. If it really works for you with the same kernel/bluetooth dongle using gnome-obex-server then just post hcidump for the working situation.

maximi89

2009-05-31 17:45

You mean the hcidump when running "python test/ods-server-test.py opp /tmp"?
or "obex-data-server"?

this is running "python test/ods-server-test.py opp /tmp"
hcidump
http://pastebin.ca/1442004 [^]

this is running normally obex-data-server
hcidump
http://pastebin.ca/1442349 [^]

skirsdeda

2009-05-31 17:47

>> I was trying gnome-obex-server and gnome-obex-send of gnome-bluetooth
>> works very well

Running what works well for you.

skirsdeda

2009-05-31 18:16

I just realised something. By saying "running normally obex-data-server" do you mean that you run ONLY obex-data-server WITHOUT ods-server-test.py or bluetooth-applet (gnome-bluetooth)??
Beware that obex-data-server DOES NOT WORK standalone!

maximi89

2009-06-01 03:49

Sorry, when i run it, i try running hcidump, ODS and bluetooth-applet, the second time, was only hcidump and ODS with --no-daemon option.

third time, hcidump and ods-server-test.py, now i going try with that you tell me.
ods-server-test.py and obex-data-server.

the test result all fine, the bug is from bluez-gnome project.

because when i run bluetooth-applet that need call automatic the server for receive files.
that happens, ODS run when bluetooth-applet are called, but can't receive files, this means:
Bluetooth-applet don't call DBUS correctly?

Thanks you for your time, ODS are running very well, bluez-gnome are buggy.

skirsdeda

2009-06-01 06:19

In recent versions, gnome-bluetooth/bluez-gnome developers have removed ods support in favor of gnome-user-share. Search for "File Sharing" (or smth like that) in your menu to find gnome-user-share configuration and enable Bluetooth file sharing there (it will enable ods).

maximi89

2009-10-19 18:04

System > Preferences > Share personal files

[maximi89@gateway ~]$ gconftool-2 --recursive-list /desktop/gnome/file_sharing
bluetooth_obexpush_enabled = true
bluetooth_accept_files = bonded_and_trusted
bluetooth_enabled = false
bluetooth_notify = true
enabled = false
require_password = never
bluetooth_require_pairing = true
bluetooth_allow_write = false

skirsdeda

2009-10-19 18:20

So what is the problem again?

skirsdeda

2009-10-19 18:22

bluetooth_enabled = false (should be true probably)
bluetooth_allow_write = false (should also be true)

maximi89

2009-10-19 19:57

how can i change that's to true?

ok, the problem seems to be a bug in gnome-user-share or a mistake in the configuration, like you see that could be more probably....

skirsdeda

2009-10-19 19:58

there's gnome-user-share gui where you can change options or you can change these options using gconftool

maximi89

2009-10-19 20:11

yes, i believe that could be a bug in the gnome-user-share

[maximi89@gateway ~]$ gconftool-2 -a /desktop/gnome/file_sharing
bluetooth_obexpush_enabled = true
bluetooth_accept_files = bonded_and_trusted
bluetooth_enabled = false
bluetooth_notify = true
enabled = false
require_password = never
bluetooth_require_pairing = true
bluetooth_allow_write = false

this is my actual configuration, and now works, the line :
bluetooth_enabled = false
only works for share from computer to out...

but the thing doesn't works to me was from phone to computer, now it works, i'm lookintg this in a bug in gnome project

https://bugzilla.gnome.org/show_bug.cgi?id=584582 [^]

thanks

you can close this bug :)

106

General

major

always

2008-07-08 13:46

2009-03-23 07:44

justinas

vygantas

normal

resolved

none

fixed

nesudeti visi actionai i weblancet_clean ir web;ancet_b_vupraktika

nesudeti info i weblancet_clean ir praktika del to negalima kai kuriu elementu istrinti ir t.t.

justinas

2009-03-23 07:44

viskas ten sutvarkyta

General

major

always

2007-02-20 01:48

2009-03-23 07:39

skirsdeda

justinas

urgent

resolved

none

fixed

Suimplementuoti 'Override' direktorija

Panaikinti 'Templates' direktorija ir vietoj to naudoti 'Override' direktorija, kur butu galima overridinti ne tik templatus bet ir klases.

skirsdeda

2007-02-20 23:56

Reikia kuo greichiau shita padaryt, bo nebus imanoma ishlaikyt esamo branchu vienodumo. Dabar isheina kad padarai pakeitima pvz lazeriuose ir reikia merginti ishkart i wl_db, auto ir wl_trunk.

justinas

2007-10-23 15:59

Is esmes jau padaryta tik pakolkas Override direktorija vadinasi Templates be to reikia visus branchus sumerginti i trunk'a.

justinas

2009-03-23 07:39

suimplementuota

104

General

major

always

2008-07-08 13:20

2009-03-23 07:32

justinas

vygantas

high

resolved

none

fixed

Neprisijungia prie TVS

Neprisijungia prie TVS jeigu esi katik atsijunges ir URL buna ?Action=Security/Logout

justinas

2009-03-23 07:32

jau veikia, ismeta action'a

157

General

major

always

2009-02-10 10:43

2009-03-05 12:28

yelo3

skirsdeda

normal

assigned

none

0.4.3

open

nokia: BT hang when copying files

versions 0.4.3 and 0.4.4
I'm using gvfs to mount and browse my nokia 6630. Then I use gnome-terminal to access it.

whenever I copy a file to my home directory (and also other destinations) the terminal hangs (the same if using nautilus) without any type of debuggung infirmation. To make it come back I have to disable BT on my nokia phone.

I don't know how to obtain further debug, can you help me?
thanks

ods.log (9 KB) 2009-02-10 14:32
ods-session-test.py (5 KB) 2009-02-10 23:39
obex.debug (32 KB) 2009-02-12 22:43

skirsdeda

2009-02-10 13:38

By "terminal" do you mean you are running obex-data-server --no-daemon? The best you can do is post output from this and optionally you could get a backtrace from gdb (so that we would see the place in code where it hangs).

yelo3

2009-02-10 14:15

Well, no. I'm using gvfs to mount, and the directory ~/.gvfs from the terminal.

Is is possible to use obex-data-server to browse the phone, so that I can identify if the problem is in o-d-s or gvfs?

skirsdeda

2009-02-10 14:20

you do it like this:
1) killall obex-data-server
2) obex-data-server -n
In another terminal:
3) /usr/libexec/gvfsd -r

Then you copy the output of both ods and gvfsd.

yelo3

2009-02-10 14:27

I managed to start it using --no-daemon as you suggested.

yelo3

2009-02-10 14:32

Now, how can I get a backrace from gdb?

skirsdeda

2009-02-10 14:39

gdb obex-data-server
>run -n

When it "hangs", you press Ctrl+c and
>bt

This will give you backtrace. However obex-data-server has to have debug symbols compiled into it (using --enable-debug).

yelo3

2009-02-10 15:05

I don't think I have --enable-debug but anyway this is what I get. Should I recompile with it?

^C Message: io callback
---Type <return> to continue, or q <return> to quit---bt
Program received signal SIGINT, Interrupt.
[Switching to Thread 0xb7b36710 (LWP 13641)]
0xb7f57430 in __kernel_vsyscall ()
(gdb) bt
#0 0xb7f57430 in __kernel_vsyscall ()
0000001 0xb7cd2a3b in poll () from /lib/tls/i686/cmov/libc.so.6
0000002 0xb7e969cb in g_poll () from /usr/lib/libglib-2.0.so.0
0000003 0xb7e89172 in ?? () from /usr/lib/libglib-2.0.so.0
0000004 0xb7e89802 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
0000005 0x080518eb in ?? ()
0000006 0xb7c0f775 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
0000007 0x0804ce81 in ?? ()

skirsdeda

2009-02-10 15:09

No need for --enable-debug in this situation. It seems that what actually hangs is gvfs obexftp backend itself. So output of '/usr/libexec/gvfsd -r' would be more helpful in this case.

yelo3

2009-02-10 15:15

and this is the output of gvfsd -r:

- do_query_info
backend_dbus_handler org.gtk.vfs.Mount:QueryInfo
Queued new job 0x98025f8 (GVfsJobQueryInfo)
+ do_query_info, filename: /C:/Nokia/Sounds/Digital/Lo chiamavano trinità.mp3
+ _query_file_info_helper, filename: /C:/Nokia/Sounds/Digital/Lo chiamavano trinità.mp3
- _query_file_info_helper
send_reply(0x98025f8), failed=0 ()
backend_dbus_handler org.gtk.vfs.Mount:QueryInfo
Queued new job 0x9802648 (GVfsJobQueryInfo)
- do_query_info
+ do_query_info, filename: /C:/Nokia/Sounds/Digital/Lo chiamavano trinità.mp3
+ _query_file_info_helper, filename: /C:/Nokia/Sounds/Digital/Lo chiamavano trinità.mp3
- _query_file_info_helper
send_reply(0x9802648), failed=0 ()
- do_query_info
backend_dbus_handler org.gtk.vfs.Mount:OpenForRead
Queued new job 0x9805090 (GVfsJobOpenForRead)
+ do_open_for_read, filename: /C:/Nokia/Sounds/Digital/Lo chiamavano trinità.mp3
+ _query_file_info_helper, filename: /C:/Nokia/Sounds/Digital/Lo chiamavano trinità.mp3
- _query_file_info_helper

yelo3

2009-02-10 15:17

Which when I disconnect BT ends with:
** Message: ErrorOccurred
** Message: Error name: org.openobex.Error.LinkError
** Message: Error message: Connection error
** Message: link lost to remote device

yelo3

2009-02-10 15:22

the gvfsd stacktrace is the same of obex-data-server

skirsdeda

2009-02-10 15:32

It seems that you have non-english character in filename ('à'). Does the same thing happen with filenames without non-engligh characters?

yelo3

2009-02-10 15:38

I tried to transfer "roma3.bmp" with the same results (I've not tried the backtraces, only the hangs)

is it possible that the problem is the name of "C:" directory?
Are you sure that it is a gvfs prpblem?
Can I test file trasfter without using gvfs?

skirsdeda

2009-02-10 15:41

"C:" directory is definitely not causing this problem.
Now I'm not so sure it's gvfs problem :)
You could test without gvfs. It will be a bit trickier. I'll post you the instructions soon.

yelo3

2009-02-10 15:51

Thank you very much! I really enjoy this quick support.
I hope it's not gvfs, since the support there is really slow

skirsdeda

2009-02-10 16:02

I have attached ods-session-test.py script here. You will need to edit it before running.
Open it and change:
bt_address to you device's bluetooth address
folder_to_go_to to some folder in your device (only one level, so you could use 'C:' for example)
file_to_send to some local file (full path)

Then run this script without any arguments, e.g. ./ods-session-test.py
It will test all the capabilities of your device in one go.

yelo3

2009-02-10 16:39

I removed the exit() at line 28 because it caused the exit of the program after printing "0"

now the output is:
0
Session object: /org/openobex/session0

nothing else

yelo3

2009-02-10 16:43

and this in obex-data-server

** Message: obex-data-server 0.4.4
** Message: Using Session bus
** Message: Parsed[0]: ftp
** Message: FTP uuid selected, first checking for Nokia OBEX PC Suite Services uuid
** Message: Connected SDP session
** Message: SDP search process
** Message: SDP search completed
** Message: getting RFCOMM channel
** Message: Connect in progress
** Message: Connected
** Message: Session created by: :1.106
** Message: io callback
** Message: event: 3
** Message: obex_request_done: command 0, response 32 (OK, Success)
** Message: Version: 0x10. Flags: 0x00 OBEX packet length: 65535

** Message: session_connect_result_cb

skirsdeda

2009-02-10 19:09

So now I have the suspicion that OBEX Connect command fails because it sends default FTP uuid. This PC Suite service might require it's own UUID in connect command. I'll try to implement this and let you know when it's done.

yelo3

2009-02-10 19:21

Don't know if it helps, but when using syncml I have to pass the identifier "PC Suite"

skirsdeda

2009-02-10 21:38

Please check with newest ods svn. Now it should use correct UUID for OBEX Connect.

yelo3

2009-02-10 22:38

Now it does not connect: I tried 2 times

** Message: obex-data-server 0.4.4
** Message: Using Session bus
** Message: Parsed[0]: ftp
** Message: FTP uuid selected, first checking for Nokia OBEX PC Suite Services uuid
** Message: Connected SDP session
** Message: SDP search process
** Message: SDP search completed
** Message: getting RFCOMM channel
** Message: Connect in progress
** Message: Connected
** Message: Using Nokia PC Suite services UUID for CMD_CONNECT
** Message: Session created by: :1.238
** Message: io callback
** Message: event: 3
** Message: obex_request_done: command 0, response 68 (Not found)
** Message: session_connect_result_cb
** Message: session closed
** Message: Removing listened DBUS name :1.238 (object: /org/openobex/session0)
** Message: Parsed[0]: ftpistened DBUS names list
** Message: FTP uuid selected, first checking for Nokia OBEX PC Suite Services uuid
** Message: Connected SDP session
** Message: SDP search process
** Message: SDP search completed
** Message: getting RFCOMM channel
** Message: Connect in progress
** Message: Connected
** Message: Using Nokia PC Suite services UUID for CMD_CONNECT
** Message: Session created by: :1.242
** Message: io callback
** Message: event: 3
** Message: obex_request_done: command 0, response 68 (Not found)
** Message: session_connect_result_cb
** Message: session closed
** Message: Removing listened DBUS name :1.242 (object: /org/openobex/session1)
** Message: Removed from listened DBUS names list
** Message: closing connection

skirsdeda

2009-02-10 22:55

FAIL :)
But with ods 0.4.4 using nautilus you get folder listings, right? It's only file sending that doesn't work.

yelo3

2009-02-10 22:59

with the ubuntu package 0.4.4-0ubuntu1 I can browse well. Also sending files works, using both copy/paste and the bluetooth applet. Only retreiving the file does not work

skirsdeda

2009-02-10 23:02

Try running ods-session-test.py with using ods 0.4.4. The problem is probably in gvfs..

yelo3

2009-02-10 23:12

As I've already told you, ods-session-test.py has 2 problems:
- it exits after checking the USB connections
- it hangs waiting for the 'connected' event

could you please see if you made an error in the code?

skirsdeda

2009-02-10 23:39

Sorry, I'm stupid today :D

Reattached fixed ods-session-test.py.

yelo3

2009-02-10 23:44

Hang when transferring file:

Session object: /org/openobex/session4
Connected
>>> RetrieveFolderListing()
<?xml version="1.0"?>
<!DOCTYPE folder-listing SYSTEM "obex-folder-listing.dtd"
  [ <!ATTLIST folder mem-type CDATA #IMPLIED>
  <!ATTLIST folder label CDATA #IMPLIED> ]>
<folder-listing version="1.0">
   <folder name="C:" user-perm="RW" mem-type="DEV" label="Memoria telefono"/>
   <folder name="E:" user-perm="RW" mem-type="MMC" label="Memory card"/>
</folder-listing>
>>> GetCurrentPath()
/
>>> ChangeCurrentFolder(C:)
>>> RetrieveFolderListing()
<?xml version="1.0"?>
<!DOCTYPE folder-listing SYSTEM "obex-folder-listing.dtd"
  [ <!ATTLIST folder mem-type CDATA #IMPLIED>
  <!ATTLIST folder label CDATA #IMPLIED> ]>
<folder-listing version="1.0">
   <parent-folder />
   <folder name="cache" modified="20050101T192432Z" user-perm="RWD" mem-type="DEV"/>
   <folder name="LOGS" modified="20050101T192434Z" user-perm="RWD" mem-type="DEV"/>
   <folder name="mmsvar" modified="20050101T192430Z" user-perm="RWD" mem-type="DEV"/>
   <folder name="Nokia" modified="20050101T192430Z" user-perm="RWD" mem-type="DEV"/>
</folder-listing>
>>> CreateFolder(Nonsense)
>>> GetCurrentPath()
C:/Nonsense/
>>> ChangeCurrentFolderBackward()
>>> GetCurrentPath()
C:/
>>> DeleteRemoteFile(Nonsense)
>>> SendFile(/home/yelo3/gmon.out)
>>> IsBusy()
1
Transfer started (gmon.out, /home/yelo3/gmon.out, 45747)
>>> GetTransferInfo()
-- Size = 45747
-- RemoteFilename = gmon.out
-- LocalPath = /home/yelo3/gmon.out
-- Time = 200
Progress: 100 %
Progress: 100 %
Transfer completed
>>> IsBusy()
0
>>> CopyRemoteFile(gmon.out, /home/yelo3/gmon_1.out)
Progress: 0 %

skirsdeda

2009-02-10 23:48

And ods output for that?

yelo3

2009-02-10 23:52

Really similar: it ends with lots of
** Message: io callback

skirsdeda

2009-02-10 23:57

Ok, then just try running ods-session-test with a file larger than 65535 bytes.

yelo3

2009-02-11 00:07

Again the file (6 Mb) is transferred but cannot be retreived

skirsdeda

2009-02-11 00:24

What a sad day today :( When fixing ods-session-test I discovered SEGFAULT in openobex and I still can't figure out this bug. The only thing that strikes me is that your Nokia requires 65535 packet length (which is a maximum and is rarely used). I remember testing ods with this packet length by sending from ods to ods and there were some hangs AFAIK. That's why ods uses 32767 byte packet length. To sum up, this bug will need some peculiar investigation :) Thanks for your superb cooperation, I'll let you know when I figure smth out.

yelo3

2009-02-11 00:41

I also had one segfault using the svn version... That's why I really hate C in favour to C# or Java!
anyway where did you see that my nokia requires 65535 packets? the result with a larger file was exactly the same

At home I have other nokia phones to test, but I'll be back on friday. In this time we can still continue to test my 6630. Anyway I remember that in the past the gnome-vfs-obexftp backend used to work, so I don't think my nokia is broken

skirsdeda

2009-02-11 00:44

You can see in ods.log that your Nokia suggests 65535 packet length when connecting.

skirsdeda

2009-02-11 00:53

BTW, I also favour C# and Java but we have to wait at least 10 years until libraries are developed using high level languages :) And having in mind that Apple uses objective C exclusively (and GNOME prefers pure C), maybe even more years :D

yelo3

2009-02-11 01:00

I think C# is quite complete now. It has glib, gtk, dbus...
Could this app be written using it? or the usb & bt libraries are not present in c#?

skirsdeda

2009-02-11 02:00

While Bluez DBus API could be used in C#, no C# bindings exist for libbluetooth, openobex and libusb. And openobex has such a bad design that writing any bindings for it would be plain stupid :D

yelo3

2009-02-11 13:25

just for a test I used windows with nokia pc suite, and it worked.

I also tried on linux using obexftp
obexftp -b "Nokia 6630" -B 12 -g E:/gmon.out
which worked too

skirsdeda

2009-02-11 13:46

It worked with obexftp probably because it doesn't care about packet length. It probably uses the same default all the time.

yelo3

2009-02-11 13:50

Where can I change packet length in the source, so that I can test if it works?

yelo3

2009-02-11 14:07

... I changed the file and this time worked... (I'm running svn now)
it seems related on the file content maybe?

I was able to retreive a text file of 9 bytes (there are some errors but it worked) the two files have the same content!!!

this is the final part of the output of ods-test:
>>> CopyRemoteFile(test.txt, /home/yelo3/test_1.txt)
Progress: 0 %
Transfer started (test.txt, /home/yelo3/test_1.txt, 0)
>>> GetTransferInfo()
-- Size = 0
-- RemoteFilename =
-- LocalPath =
Progress
Transfer completed
>>> DeleteRemoteFile(test.txt)
>>> SendFile(/home/yelo3/test.txt)
>>> Cancel()
Failed: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Progress
Transfer completed
>>> ChangeCurrentFolderToRoot()
Failed: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
>>> GetCurrentPath()
Failed: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
False
>>> GetCapability()
Failed: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
False
>>> Disconnect()
Failed: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

and this is obex-data-server -n:
** Message: obex-data-server 0.4.4
** Message: Using Session bus
** Message: Parsed[0]: ftp
** Message: FTP uuid selected, first checking for Nokia OBEX PC Suite Services uuid
** Message: Connected SDP session
** Message: SDP search process
** Message: SDP search completed
** Message: getting RFCOMM channel
** Message: Connect in progress
** Message: Connected
** Message: Session created by: :1.234
** Message: io callback
** Message: event: 3
** Message: obex_request_done: command 0, response 32 (OK, Success)
** Message: Version: 0x10. Flags: 0x00 OBEX packet length: 65535

** Message: session_connect_result_cb
** Message: LOCK ods_session_get_by_type
** Message: io callback
** Message: event: 9
** Message: There is some data
** Message: Writing to buf
** Message: event: 9
** Message: event: 3
** Message: obex_request_done: command 3, response 32 (OK, Success)
** Message: UNLOCK obex_request_done
** Message: LOCK ods_session_setpath
** Message: io callback
** Message: event: 3
** Message: obex_request_done: command 5, response 32 (OK, Success)
** Message: UNLOCK obex_request_done
** Message: LOCK ods_session_get_by_type
** Message: io callback
** Message: event: 9
** Message: There is some data
** Message: Writing to buf
** Message: event: 9
** Message: event: 3
** Message: obex_request_done: command 3, response 32 (OK, Success)
** Message: UNLOCK obex_request_done
** Message: LOCK ods_session_setpath
** Message: io callback
** Message: event: 3
** Message: obex_request_done: command 5, response 32 (OK, Success)
** Message: UNLOCK obex_request_done
** Message: LOCK ods_session_setpath
** Message: io callback
** Message: event: 3
** Message: obex_request_done: command 5, response 32 (OK, Success)
** Message: UNLOCK obex_request_done
** Message: LOCK ods_session_delete_remote_file
** Message: io callback
** Message: event: 3
** Message: obex_request_done: command 2, response 32 (OK, Success)
** Message: UNLOCK obex_request_done
** Message: LOCK ods_session_send_file_ext
** Message: event: 8
** Message: obex_writestream
** Message: writestream from File: 7
** Message: event: 8
** Message: obex_writestream
** Message: writestream from File: 7
** Message: read 0 bytes (EOF)
** Message: UNLOCK ods_session_send_file_ext
** Message: io callback
** Message: event: 3
** Message: obex_request_done: command 2, response 32 (OK, Success)
** Message: LOCK ods_session_copy_remote_file_full
** Message: UNLOCK ods_session_copy_remote_file_full
** Message: io callback
** Message: event: 0

** (obex-data-server:12690): WARNING **: PROGRESS: 0
** Message: io callback
** Message: event: 9
** Message: There is some data
** Message: event: 9
** Message: event: 3
** Message: obex_request_done: command 3, response 32 (OK, Success)

** (obex-data-server:12690): WARNING **: MODTIME: -1
** Message: LOCK ods_session_delete_remote_file
** Message: io callback
** Message: event: 3
** Message: obex_request_done: command 2, response 32 (OK, Success)
** Message: UNLOCK obex_request_done
** Message: LOCK ods_session_send_file_ext
** Message: event: 8
** Message: obex_writestream
** Message: writestream from File: 7
** Message: event: 8
** Message: obex_writestream
** Message: writestream from File: 7
** Message: read 0 bytes (EOF)
** Message: UNLOCK ods_session_send_file_ext
** Message: LOCK ods_session_cancel
** Message: io callback
** Message: event: 3
** Message: obex_request_done: command 2, response 32 (OK, Success)
** Message: LOCK ods_session_setpath

yelo3

2009-02-11 14:13

It also works with jpg files.

yelo3

2009-02-11 14:24

Alsu using gvfs works, but lets me do only 1 transfer, then it hangs.

Maybe it's exactly the same thing which happens using the yout test script: after the transfert nothing else will work.

yelo3

2009-02-11 14:31

It also works with 0.4.4-0ubuntu1 ubuntu original............
I really can't understand!!!! I did exactly the same operations of yesterday from nautilus!
(still only 1 file copy works)

skirsdeda

2009-02-12 18:44

I tested with maximum packet length and something very wrong happens inside openobex. The only way to fix this is to actually analyze what's happening there and believe me, openobex code base is really difficult to understand :)

yelo3

2009-02-12 18:50

My tests were done without any change in packet length. I'm using plain ubuntu packages.
Are you are able to understand what happens when the file transfert ends, and why dbus will not answer

skirsdeda

2009-02-12 21:23

It turns out that openobex fails to receive packets larger than 43344 bytes! I don't know where this magic number comes from yet :) openobex is just a huge pain in the ass.

skirsdeda

2009-02-12 21:36

You could confirm this by compiling openobex with debug output enabled. You would have to get openobex source and do smth like this:
./bootstrap
./configure --prefix=/usr --enable-debug
then change OBEX_DEBUG to 4 in config.h
make
make install

Then ods output will have openobex debug output as well.

yelo3

2009-02-12 22:43

I downloaded openobex-1.4 from bluez site
./bootstrap was not present, so I passed to ./configure etc.

I executed the usual things and collected the output (I killed obex-data-server as soon as the first dbus error), which I will attach now

yelo3

2009-03-05 12:28

Just to inform you, also fedora 11 alpha has this issue

153

General

major

N/A

2009-01-27 04:41

2009-02-08 17:25

cosimoc

skirsdeda

normal

closed

none

0.4.2

fixed

RemoteCopy and RemoteMove methods haven't been added to the DBus XML descriptor.

SSIA, patch attached.

remote-methods.patch (2 KB) 2009-01-27 04:41

skirsdeda

2009-01-27 13:27

Fixex in svn rev 2473. Sorry for such a stupid bug :)

148

General

major

always

2008-11-20 03:56

2009-02-08 17:25

skirsdeda

normal

closed

none

0.4.2

fixed

After calling CancelSessionConnect, unable to reconnect OBEX server for about 1 minute.

If we cancel the client connection while the OBEX server is waiting to determine whethere to accept or reject our connection, ODS and our application terminates the onging connection without problems. But if we try the connection again to the same target, the connection fails for about 1 minutes. After that period we can connect it normally.

I attach the ODS logs below.

(1st client connect and cancel connect)
** Message: Parsed[0]: ftp
** Message: Connected SDP session
** Message: SDP search process
** Message: SDP search process
** Message: SDP search completed
** Message: getting RFCOMM channel
** Message: Connect in progress
** Message: session closed
** Message: Removing listened DBUS name :1.78 (object: /org/openobex/session6)

(2nd client connect trial)
** Message: Parsed[0]: ftp
** Message: Connected SDP session
** Message: SDP search process
** Message: SDP search process
** Message: SDP search completed
** Message: getting RFCOMM channel
** Message: session closed
** Message: Removing listened DBUS name :1.78 (object: /org/openobex/session7)

skirsdeda

2008-11-27 19:53

Fixed in svn revision 2265. Check if it works.

151

FTP

major

always

2008-12-02 07:43

2009-02-07 00:12

skirsdeda

normal

closed

none

0.4.2

fixed

"local_file_test" for GET operation fails if I pass a location to save a file.

Using the newest ODS code from SVN, if I call "ods_session_copy_remote_file" ODS now checks the local path using g_file_test but the local path means the path where received file will be saved as explained in "dbus-api.txt" file. So if I pass a location at which I want to save a received file, g_file_test fails because the location is empty currently. Previous ODS only checks if the local_path is "\0". I wonder if the meaning of the local_path has changed.

skirsdeda

2008-12-02 13:06

Sorry, this is my mistake. Will be fixed.

skirsdeda

2009-01-16 17:05

Sorry for a long delay. This one is fixed in svn now.

General

major

always

2008-03-13 15:01

2008-10-17 19:59

prahal

skirsdeda

normal

closed

none

0.3

no change required

if I set my adapter in place of the default in test/ods-server-test.py obex-data-manager fails to register to sdp

I found that in case the adapter is not set to default ods-bluez.c set the dbus proxy to the path of the adapter instead of /org/bluez :
get_database_proxy :

database_proxy = dbus_g_proxy_new_for_name (klass->connection,
                                                                                                        "org.bluez",
                                                                                                        adapter_object,
                                                                                                        "org.bluez.Database");

This makes calls to AddServiceRegister to fail with :
"Method "AddServiceRecord" with signature "ay" on interface "org.bluez.Database" doesn't exist"
which I first though was an error in the call but in fact is an error in the path . /org/bluez/hciX (here hci0) does not have Database interface thus it fails.

To fix it I replaced adapter_object by "/org/bluez". I do nto send it as a patch because it is a hack . I guess that if adapater_object is of no use the whole function could be simplified to only be :
static DBusGProxy*
get_database_proxy (OdsBluez *bluez, const gchar *device)
{
        GError *error = NULL;
        DBusGProxy *database_proxy;

        OdsBluezClass *klass = ODS_BLUEZ_GET_CLASS (bluez);

        database_proxy = dbus_g_proxy_new_for_name (klass->connection,
                                                                                                        "org.bluez",
                                                                                                        "/org/bluez",
                                                                                                        "org.bluez.Database");

        return database_proxy;
}

And even the device argument could go away but this would break api so I don't know (is this function internal ?)

Best regards
Alban

skirsdeda

2008-03-13 22:56

obex-data-server will not be fixed. bluez will be fixed though. I wrote code for obex-data-server according to bluez documentation, but it turns out that this feature isn't implemented yet. I will do a patch for bluez-utils and it should work just fine.

General

major

always

2008-02-27 20:52

2008-10-17 19:59

hadess

skirsdeda

high

closed

none

fixed

Accept/Reject doesn't work for short files

The attached patch adds Accept/Reject support to the test server.

It fails to work for short files (in this case a todo item from my Nokia phone, 246 bytes) though, it works well with larger files (photos sent from the phone).

Marking as major severity and private, as it's a potential security issue.

Log with the short file:

$ ./ods-server-test.py opp ~/Desktop/Downloads/
Server object: /org/openobex/server2
Started
Session created: /org/openobex/serversession2
Session Bluetooth address: 00:12:D2:79:B7:33
>>/org/openobex/serversession2<< Transfer started (Nokia.vcs, /home/hadess/Desktop/Downloads/Nokia(2).vcs, 246)
ERROR:dbus.connection:Exception in handler for D-Bus signal:
Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/dbus/connection.py", line 210, in maybe_handle_message
    self._handler(*args, **kwargs)
  File "./ods-server-test.py", line 49, in transfer_started_cb
    self.session.Accept()
  File "/usr/lib/python2.5/site-packages/dbus/proxies.py", line 135, in __call__
    **keywords)
  File "/usr/lib/python2.5/site-packages/dbus/connection.py", line 603, in call_blocking
    message, timeout)
DBusException: org.openobex.Error.Failed: There is no transfer in progress
>>/org/openobex/serversession2<< Transfer completed
>>/org/openobex/serversession2<< Disconnected
Session removed: /org/openobex/serversession2

Log with the bigger file:

$ ./ods-server-test.py opp ~/Desktop/Downloads/
Server object: /org/openobex/server0
Started
Session created: /org/openobex/serversession0
Session Bluetooth address: 00:12:D2:79:B7:33
>>/org/openobex/serversession0<< Transfer started (Image000.jpg, /home/hadess/Desktop/Downloads/Image000(1).jpg, 673328)
>>/org/openobex/serversession0<< Progress: 0 %
>>/org/openobex/serversession0<< Transfer cancelled
>>/org/openobex/serversession0<< Disconnected
Session removed: /org/openobex/serversession0

ods-auto-accept-test.patch (1 KB) 2008-02-27 20:52
ods-accept-bug-log.txt (2 KB) 2008-03-01 15:26
ods-accept-bug-log-2.txt (2 KB) 2008-03-02 04:45
ods-accept-bug-log-working.txt (64 KB) 2008-03-02 04:49
openobex_cvs.patch (0 KB) 2008-05-12 23:00

skirsdeda

2008-03-01 01:48

Updated ods-server-test.py included in svn. Can't reproduce this though...

hadess

2008-03-01 02:20

I can reproduce this every time. I've attached a log of ods server with debug enabled. Feel free to give me patches with more debug if you feel necessary.

skirsdeda

2008-03-01 15:15

Don't see that ods log

hadess

2008-03-01 15:27

My mistake, got confused by mantis.

skirsdeda

2008-03-01 17:13

Ok, this gives me some information. Could you also send ods log when receiving bigger file?

skirsdeda

2008-03-01 22:07

from ods-accept-bug-log.txt:
** Message: obex-data-server 0.01

I don't get this :) Should be 0.3, but judging from other info, this is at least 0.2

hadess

2008-03-02 04:46

Must have been some left-over files from a previous build. Still happening with the current SVN after a rebuild.

skirsdeda

2008-03-02 16:49

Ok, I figured this out. The problem is that if entire file is sent in first request (along with filename, length, etc), request cannot be suspended (to wait for Accept()/Reject()). A workaround should be implemented in ods. Transfer shouldn't be finished until Accept()/Reject() is called, in this case Accept() would just finish transfer and Reject() would delete received file.

skirsdeda

2008-03-26 13:00

Making this public to avoid more dups.

skirsdeda

2008-03-26 13:04

Accept()/Reject() currently doesn't work AT ALL. It's because request is suspended in wrong place.

heston_james

2008-04-05 18:32

When we're talking about 'small files' so we actualy know what the size limit is? From my experience this is quite normal behaviour, I know the OBEX servers on some brands of mobile phone seem to work in this fasion and place in a work around which stops the file from being saved untill it is 'accepted'.

Once we've moved the Accept/Reject into the correct location I cant see that it would be too much work to build in a workaround, provided we can identify the size of file which is currently slipping through the net.

Do we know it? or would you like me to carry out some testing to resolve this?

Heston.

skirsdeda

2008-05-12 21:48

Made some good progress with this bug. It turns out that Accept/Reject won't work with openobex 1.3, we need cvs version (with one wrong line of code removed). This is because we need to suspend the request _before_ first packet is sent and this is not supported in openobex 1.3.

Did some initial testing and Accept/Reject seems to work the way it is supposed to. There are still several uncertainties left which I have to check.

skirsdeda

2008-05-12 23:02

Fix commited to svn. Use openobex cvs version with attached patch (openobex_cvs.patch) to test.

Set auto_accept = False in ods-server-test.py to test Accept/Reject.

103

General

major

have not tried

2008-07-03 16:40

2008-10-17 19:59

skirsdeda

normal

closed

none

fixed

Problems when selecting different hci dev for session

Sometimes when connecting session, binding to hci dev fails.

close.patch (2 KB) 2008-07-13 19:43

heston_james

2008-07-03 17:01

Hi Skirs,

From testing done by myself and kpanic it would seem that this only occurs when session connects fail, I would guess that the session is not properly finalized if it fails to connect, thus leaving dead bondings to the local adapters.

Heston.

skirsdeda

2008-07-03 17:17

In svn rev 1595 I included errno in error message. Try again and see what errno you get in error message.

heston_james

2008-07-03 18:08

org.openobex.Error.ConnectionAttemptFailed, Binding to local device failed (errno: 98))

Cheers,

Heston

skirsdeda

2008-07-03 18:13

As suspected, we get EADDRINUSE.

heston_james

2008-07-03 18:28

Ok, so do we think this is because the socket isnt being closed when the session fails to connect?

Heston

skirsdeda

2008-07-03 18:29

yes, either it isn't closed (which I doubt) or we try to connect too early (before it is fully closed)

manuel

2008-07-13 19:42

Hello everyone,

I think it actually it's a collision, bluetooth acl connections aren't closed immediately it takes some seconds to be closed. So if you call connect right after you called close it will lead to those kinds of errors.

Besides there's another problem going on, if you use dbus-python then an object will only be unreferenced when you remove all the signals listeners that it has, so that prevents ods_session_dispose from been called. I created a page in the wiki to show how to avoid this problem: http://wiki.muiline.com/obex-data-server/coding_tips [^] this one isn't yet referenced from the main page, I would like Tadas to review it first. We should add this too all the "official" samples (test codes).

The patch I'm including fixes too thing. One is minor, that when we bind to the local device we should use channel 0, so it's bluez the one that decide which rfcomm channel is free for been used, we only have to force the target channel, not the local one. Bluetooth is smart enough to cross rfcomm ports if needed.

The other part is to make Close from ServerSession to really match the specs, this means that a call to close really closes the socket connection, and not doing it like it's done right now that's waiting until ods_session_dispose is called. I haven't removed close from ods_session_disposse just calling it from ods_session_close and mark it as invalid, so session_dispose doesn't close it.

Please review the patch, comments are welcomed.

Thanks,
Manuel Naranjo
Wireless Cables Inc.
www.aircable.net

heston_james

2008-07-14 10:55

Good morning Manuel,

Thank you for the Wiki entry, that certainly makes it a lot clearer. I have had problems with that in the past I'm sure where I was reaching the limit of file descriptors but couldnt find out what was causing it, I'm guessing this was the reason. I'll look at implementing that structure into my app, I did speak with the Dbus guys at the time about it but we were never able to trace exactly what I was doing wrong. However, I've not seen those errors in some time now.

I've been shaping up these test scripts this morning, I'm just off out for a short while now but will begin to test when I get back. I'll start by testing with the patch you've attached to see if that makes any difference, failing that I'll try implementing those modifications into my python code.

Iether way we'll be much more informed by the end of the day after we've tested.

What testing, if any, have you had chance to do? and what results have you had?

Cheers,

Heston

skirsdeda

2008-07-21 15:20

Patch applied in svn (except for socket closing in close(), because session.Close() causes session_finalize to be called just after it anyway). Thanks for patch.

Are all the symptoms of this bug gone with newest svn?

heston_james

2008-07-21 18:14

Skirs,

I've been testing with this svn this morning and been creating hundereds of sessions without it causing any problems, I'm fairly sure that this bug has been fixed by this latest release :-)

Thanks,

Heston

skirsdeda

2008-07-21 18:15

Marking as resolved then

General

major

N/A

2008-05-09 17:07

2008-10-17 19:59

cktakahasi

skirsdeda

normal

closed

none

0.3.1

fixed

Use BlueZ 4.0 API

BlueZ D-Bus API 3.X are going to be deprecated. ODS needs to be converted to the new API.

new_api.patch (1 KB) 2008-07-02 18:17
ods_bluez4_api.patch (2 KB) 2008-07-06 01:23

heston_james

2008-05-12 15:48

This is definitily something which needs to be looked at, I wonder when though. Do we have any idea when a stable release of BlueZ using this new API is due for public release? I dont think we need worry untill then.

At the moment I use the old API for other applications and wouldnt be upgrading my distribution untill I could be sure it was stable.

Heston.

skirsdeda

2008-06-28 21:17

I am gonna do a compile-time option for bluez 4.x API.

heston_james

2008-06-29 12:57

Thats a very nice idea Skirs I appreciate that it'll make life a little trickier from a code standpoint, but for the moment I think a large majority will still likely use whatever version of bluez is in the stable apt repositoties.

Good man,

Heston

manuel

2008-07-02 18:17

This patch works the same way bluez does.

In bluez to enable the 4.0 API you need to tell hcid to use it by passing -x to it.

Well this patch does exactly the same, and shares a function to all the rest of the code that lets it know which API should be used.

Thanks,
Manuel Naranjo
manuel at aircable dot net

skirsdeda

2008-07-04 01:45

It's wrong to have ods_use_new_bluez_api() defined in ods-common.h and implemented in ods-main.c. header and implementation files must match. The correct way would be to have a variable and two functions (set/get) defined in ods-common.c, then from ods-main.c you would call set function and use get function everywhere else.

manuel

2008-07-06 01:22

Mhh that makes sense, updated patch.

I also added short commands versions for no-daemon and system-bus.

Does it make any sense to provide a method that allows to know the API been used from the dbus client side?

skirsdeda

2008-07-10 15:24

This patch has to include actual changes to bluez.c (SDP record searching) to use 4.x API.

manuel

2008-07-13 23:39

Actually the old api is still available even though if the new one is registered. So there's no fear it will break anything, and we can do this stuff more slowly.

But we need an option in runtime to tell if we're using or not the new api so we can use this new features.

Anyway BlueZ 4.0 will not start to be really developed any time soon, so there's no rush, I don't think you should mark this really needed for 0.4

heston_james

2008-08-04 18:02

Manuel,

Just to enhance on your idea:

"But we need an option in runtime to tell if we're using or not the new api so we can use this new features."

This would be a nice idea, I would like to see another method on the manager object perhaps like GetVersion() which returns the version number for ODS which is being used, these things can sometimes come in handy for logging on our higher level apps.

Heston

skirsdeda

2008-09-23 18:36

Fixed in svn rev 1950

136

General

major

always

2008-09-25 14:01

2008-10-17 19:59

heston_james

skirsdeda

normal

closed

none

fixed

SDP Starts to fail after running for a while.

Morning Tadas,

After running some tests with the latest SVN this past 24 hours I've seen an issue arise. Seems that after having been running for a considerable amount of time and creating a few thousand sessions all connection attempts start to fail with the following error message:

org.openobex.Error.ConnectionAttemptFailed, Service search failed (Too many open files)

I'll leave it with you, if you want me to give you any more info then please feel free to ask :-)

Cheers,

Heston

valgrind_output (81 KB) 2008-09-26 17:09
strace_out (100 KB) 2008-10-03 18:15

skirsdeda

2008-09-26 01:53

Probably successful SDP transactions aren't closed properly. Should be easy to fix.

heston_james

2008-09-26 10:46

Yeah I think you're right, something just isnt being closed off properly, just need tracing through the process.

skirsdeda

2008-10-09 23:25

So this should be fixed now. Heston, have you done some more testing regarding this? We can probably close this bug now.

heston_james

2008-10-10 12:49

Morning Tadas,

I've rolled this fixed version onto a few production boxes and havnt seen the issue yet so I'm fairly convinced this has now been resolved :-) nice work!

I think its safe to close the ticket, if I see it happening again we'll reopen it.

Cheers,

Heston

107

General

major

always

2008-07-11 17:49

2008-10-17 19:59

monreal

skirsdeda

normal

closed

none

0.3.1

fixed

File transfers hanging with gnome-user-share

Note that this is most likely a bug in gnome-user-share but it would be great if you could confirm and point into the right direction.

The problem: sending files larger than 7.9kb gets stuck and I have to cancel the transfer when using gnome-user-share. With a simple test setup like this it works great, though:

obex-data-server --no-daemon
ods-server-test.py opp ~/Download/

I'll attach the obex-data-server and hcidump logs for both the test setup (test) and gnome-user-share (gus) runs.

test.log (3 KB) 2008-07-11 17:50
gus.log (2 KB) 2008-07-11 17:50
hcidump-test.log (132 KB) 2008-07-11 17:51
hcidump-gus.log (74 KB) 2008-07-11 17:51

manuel

2008-07-11 22:57

Mhh seems like a bug in gus to me, I'll try to take a look at it if I can.

skirsdeda

2008-07-14 05:01

No need to look at it, I know what's wrong. It's openobex.

monreal

2008-07-17 18:03

skirsdeda, I was already told that openobex is the problem on IRC. But now I wonder what the correct way to get things working is. I'm using openSUSE 11.0, which ships openobex 1.3. If I understand correctly, even openobex trunk won't work without further patching? Would be nice to hear what I need to build a working package for 11.0 (and have everything work out of the box in the next release).

skirsdeda

2008-07-17 18:32

openobex didn't have any releases for 2 years. It's not clear who is in charge, so it would be difficult to do a release with that patch included. Even trunk (if you are referring to http://dev.zuckschwerdt.org/openobex/browser/trunk) [^] needs the same patch.

There are several ways to solve this:
1) Temporary solution to disable Accept/Reject functionality in ods (as it was in releases previously to 0.3.2)
2) Include patch in openobex 1.3 package.
3) Include patch in openobex trunk and push for new release.

monreal

2008-07-19 01:29

Still a bit confused... does the openobex version shipped by Fedora¹ work for example? If yes, which is the magic patch?

[1] http://cvs.fedoraproject.org/viewcvs/rpms/openobex/devel/ [^]

heston_james

2008-07-19 12:19

Just my two pence on this, but having a feature in ods which requires a patched version of a lower level app is likely to cause all kinds of headaches.

I would think that the only two real options are to iether remove this feature from ods, or get a new release of open obex, I think any other option is likely just to cause confusion for more people, as it has done so here :-).

The third viable option would be to include it in ods, but have it as a configure option that has to be set to enable it, --enable-accept-reject or something like that.

I think its important that people using the release version of ods and a release version of openobex dont have a broken version.

Heston

monreal

2008-07-19 15:25

>> Temporary solution to disable Accept/Reject functionality
>> in ods (as it was in releases previously to 0.3.2)

So you say, things should work fine with ods 0.3/0.3.1? I downgraded to 0.3 and I see the same problem (file transfer stopping after a few kb)...

So, what's the official solution (or workaround)?

Please, either:

a) provide a patch against latest ods to remove the feature
b) release a new ods, which includes the feature conditionally
c) provide a patch against the latest openobex release (1.3) and ask distributions to ship this as long as there is no new openobex release

skirsdeda

2008-08-23 22:00

I managed to get Accept/Reject functions work without patching openobex.
The newest ods from svn works correctly. This fix will be available in obex-data-server 0.3.5.

General

major

always

2008-05-11 21:37

2008-10-05 19:49

Vudentz

normal

closed

none

0.3.1

open

Use of dbus_g_proxy_call may cause ods to block

dbus_g_proxy_call is known to be synchronous call that wait for the reply while it blocks the mainloop. This behavior is very undesirable on daemons, specially dbus daemons as ods, since it make the process unresponsive until a reply/error is received back.

123

BIP

major

always

2008-08-21 02:59

2008-09-13 02:25

cktakahasi

normal

new

none

0.3.4

open

BIP - Cancel + re-send doesn't work

It is not possible send an image after Cancel a session. See the log in the "Additional Information" field.

# Testing on HP PhotoSmart

####### Sending first image using ods-bip-test.py

** (obex-data-server:8993): WARNING **: PROGRESS: 91692
** Message: io callback
** Message: event: 8
** Message: obex_writestream
** Message: writestream from File: 9
** Message: event: 8
** Message: obex_writestream
** Message: writestream from File: 9
** Message: io callback
** Message: event: 3
** Message: obex_request_done: command 2, response OK, Success
** Message: LOCK
** Message: Sending CMD_DISCONNECT
** Message: UNLOCK
** Message: io callback
** Message: event: 3
** Message: obex_request_done: command 1, response OK, Success
** Message: LOCK
** Message: UNLOCK
** Message: session closed
** Message: Removing listened DBUS name :1.76 (object: /org/openobex/session0)
** Message: Removed from listened DBUS names list
** Message: closing connection

#### Pressing Cancel in the printer and sending the same image again

** Message: Parsed[0]: bip, Parsed[1]: (null)
** Message: supp_capabilities: 0
** Message: supp_features: 1
** Message: supp_funcs: 3
** Message: data_cap: 3072000
** Message: Connecting to 00:0C:55:BC:10:85 using channel 3
** Message: Connect in progress
** Message: Connected
** Message: Imaging SDP data:
** Message: >> capabilities: 0
** Message: >> features: 1
** Message: >> functions: 3
** Message: >> capacity: 3072000
** Message: Session created by: :1.77
** Message: io callback
** Message: event: 3
** Message: obex_request_done: command 0, response OK, Success
** Message: LOCK
obex-data-server: unable to initialize module loader `Success'.

##### Pressed CTRL+c in the ods-bip-test.py

** (obex-data-server:8993): WARNING **: DBUS NAME REMOVED: :1.77

** (obex-data-server:8993): WARNING **: Finalizing session
** Message: attempting to close session

##### Bluetooth connection still open

** Message: me was killed
** Message: Disposing manager
** Message: attempting to close session

** Message: me was killed
** Message: Disposing manager

##### CTRL+c doesn't kill obex-data-server

** Message: me was killed
** Message: Disposing manager

** Message: me was killed
** Message: Disposing manager

** Message: me was killed
** Message: Disposing manager

skirsdeda

2008-08-23 00:20

Seems to be some problem with ImageMagick.

General

major

always

2008-04-01 16:56

2008-06-19 17:24

fcrozat

skirsdeda

normal

assigned

none

0.3

fixed

obex-data-server doesn't support non-UTF8 locale filename

on system using non-UTF8 french locale (fr_FR.ISO-8859-1), obex-data-server is not able to receive any file (through bluez-gnome) because XDG download dir is "~/Téléchargements" : when G_FILENAME_ENCODING is set to '@locale' (which is the case on most distributions), filename (and path) are encoded in ISO-8859-1.

Therefore, obex-data-server should use g_filename_from_utf8 (and _to_utf8) to make sure filename received / send (which should always be in UTF-8) are converted correctly to the right locale

skirsdeda

2008-04-01 17:03

Thanks for detailed bug report. Since 0.4 might be ready only in May/June, I will probably release 0.3.2 which will fix this.

skirsdeda

2008-05-07 20:44

Could someone test it with obex-data-server from subversion? I commited a fix which hopefully works :)

General

major

always

2008-02-29 22:33

2008-06-19 15:05

hadess

skirsdeda

high

closed

none

fixed

Doesn't implement Nokia UUID work-around

In gnome-vfs-obexftp, there was a work-around for Nokia phones (in particular the N70):
http://bazaar.launchpad.net/~jamesh/gnome-vfs-obexftp/devel/annotate/james%40jamesh.id.au-20070714105344-rfpan8fzk8d4l0n2?file_id=ombluetooth.c-20070610112304-bpal1vz7gu1r5z6f-1 [^]

See line 79 and below. This breaks browsing files on remote devices in that it actually connects to the standard ObexFTP channel which lists no files
(as seen in http://bugzilla.gnome.org/show_bug.cgi?id=519593) [^]

skirsdeda

2008-03-01 00:33

Such things suck hard! Nevertheless, this should be implemented in next version.

skirsdeda

2008-03-01 02:00

To implement this, some peculiar work needs to be done in ods-bluez.c, therefore it will further complicate ods-bluez.c. 0000046 has to be fixed beforehand.

hadess

2008-03-01 02:08

Completely different part of the code though.

skirsdeda

2008-05-14 02:39

Fixed in subversion (revision 1491)

General

major

always

2008-05-21 21:32

2008-06-19 15:05

cktakahasi

larry

normal

closed

none

0.3.1

fixed

Deleting a file doesn't report error properly

If the file doesn't exist or the user doesn't have permission to remove it, ODS always report success. See File Transfer Profile section "5.8.1 Deleting Files" to find which values must be returned.

*** Environment state ***
* shared folder: /tmp/ffp
Permissions:
drwxr-xr-x 2 root root 4096 2008-05-21 15:16 ftp

* folder content:
cktakahasi@krau-note:/tmp/ftp$ ls -l
total 0
-rw-r--r-- 1 root root 0 2008-05-21 14:29 ftp.txt

/* HCIDUMP: Reports success when unauthorized or the file doesn't exist */

> ACL data: handle 46 flags 0x02 dlen 35
    L2CAP(d): cid 0x0041 len 31 [psm 3]
      RFCOMM(d): UIH: cr 1 dlci 20 pf 0 ilen 27 fcs 0x31
        OBEX: Put cmd(f): len 27
        Connection ID (0xcb) = 1
        Name (0x01) = Unicode length 16
        0000: 00 6b 00 72 00 61 00 75 00 2e 00 70 00 6e 00 67 .k.r.a.u...p.n.g
< ACL data: handle 46 flags 0x02 dlen 11
    L2CAP(d): cid 0x0041 len 7 [psm 3]
      RFCOMM(d): UIH: cr 0 dlci 20 pf 0 ilen 3 fcs 0xeb
        OBEX: Put rsp(f): status 200 len 3

bug_85.patch (1 KB) 2008-05-28 00:39

larry

2008-05-28 00:39

Proposed solution attached

skirsdeda

2008-05-28 16:44

Changed ods_obex_srv_put a bit differently in svn rev 1512. Please check if put/delete works as expected.

General

major

always

2008-05-20 19:34

2008-06-19 15:05

cktakahasi

larry

high

closed

none

0.3.1

fixed

OBEX Push service can be used to send FTP commands

OBEX Push must not handle FTP commands.

How reproduce:

Host A:
1. Start the obex-data-server
2. Run an obex push server:
$./ods-server-test.py opp /tmp

Host B:
$obex_test -b xx:xx:xx:xx:xx:xx 9
Using Bluetooth RFCOMM transport
OBEX Interactive test client/server
>c
Server request finished!
server_done() Command (00) has now finished
>t bug
>> SETPATH>Server request finished
...

Probably this problem also happen with other OBEX FTP commands.

larry

2008-05-22 21:35

proposed solution http://pastebin.com/m2403343f [^]

skirsdeda

2008-05-22 23:47

Fixed in svn rev 1497. BTW, I would prefer attached patch file instead of pastebin link..

General

major

always

2008-05-12 22:49

2008-06-19 15:05

skirsdeda

larry

normal

closed

none

0.3.1

fixed

After cancelling ServerSession, ods can't exit

1) Run ods-server-test.py
2) Initiate transfer
3) Kill ods-server-test.py during transfer (ServerSession gets cancelled)
4) Kill obex-data-server

ods doesn't exit, outputs message:
** (obex-data-server:25651): WARNING **: DBus error (RemoveServiceRecord): Not available

ods-server.c.patch (1 KB) 2008-05-19 16:08

skirsdeda

2008-05-19 20:50

Why attached patch isn't the same as http://pastebin.com/m59704dae [^] ?

parent_class->dispose should get called in both cases or is there a reason for not doing so?

larry

2008-05-19 21:06

before of parent_class->dispose is called the signal of "disposed" emitted in server_session_disconnected_cb is not caught in ods-manager.c (server_disposed_cb is not called)

skirsdeda

2008-05-19 21:10

ok, but why not call parent_class->dispose in the end of server_session_disconnected_cb

larry

2008-05-19 22:04

called parent_class->dispose in server_session_disconnected_cb I receive this error

(obex-data-server:22444): GLib-GObject-WARNING **: instance with invalid (NULL) class pointer

(obex-data-server:22444): GLib-GObject-CRITICAL **: g_signal_handlers_destroy: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed

skirsdeda

2008-05-20 13:05

I'll look into this further.. Maybe it isn't worth using standard GObject dispose function at all.

skirsdeda

2008-05-23 00:02

fixed in svn rev 1498. We don't use GObject dispose functionality anymore, server object simply has ods_server_dispose function.

General

major

always

2008-05-23 00:14

2008-06-19 15:05

cktakahasi

vcgomes

high

closed

none

0.3.1

fixed

Build error on scratchbox chinook armel

make[3]: Entering directory `/home/cktakahasi/ods/src'
if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -Wall -Werror -Wcast-align -Wnested-externs -Wpointer-arith -Wsign-compare -g -O2 -g -pg -Wno-strict-aliasing -Wno-sign-compare -MT ods-bluez.o -MD -MP -MF ".deps/ods-bluez.Tpo" -c -o ods-bluez.o ods-bluez.c; \
then mv -f ".deps/ods-bluez.Tpo" ".deps/ods-bluez.Po"; else rm -f ".deps/ods-bluez.Tpo"; exit 1; fi
ods-bluez.c: In function `get_remote_service_handles_cb':
ods-bluez.c:384: warning: cast increases required alignment of target type
make[3]: *** [ods-bluez.o] Error 1
make[3]: Leaving directory `/home/cktakahasi/ods/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/cktakahasi/ods/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/cktakahasi/ods'
make: *** [all] Error 2

ods-portability.patch (2 KB) 2008-05-30 21:54

vcgomes

2008-05-30 21:54

Hi,

There were two issues associated with this problem:

- the Maemo GLib Version (2.12) doesn't has g_hash_table_get_keys()
- and the cast done in ods-bluez.c:384 isn't too portable, because the difference between the alignment of structures on x86 and Arm. memcpy will do the right thing. The attached patch tries to solve these problems.

Vinicius

skirsdeda

2008-05-30 23:54

Fixed in svn rev 1519.

General

major

always

2008-05-21 21:49

2008-06-19 15:05

cktakahasi

larry

normal

closed

none

0.3.1

fixed

Deleting a folder doesn't report errors properly

ODS returns success code in spite of error conditions.

According to the File Transfer Profile(section 5.8.2):
"Deleting a non-empty folder will delete all its contents,
including other folders. Some Servers may not allow this operation and
will return the “Precondition Failed” (0xCC) response code, indicating that the
folder is not empty."

In the test scenario, "folder1" was not removed, but success is returned.

/* Folders content */
cktakahasi@krau-note:/tmp/ftp$ ls -l
total 4
drwxr-xr-x 2 cktakahasi cktakahasi 4096 2008-05-21 15:32 folder1
-rw-r--r-- 1 cktakahasi cktakahasi 0 2008-05-21 14:29 ftp.txt
cktakahasi@krau-note:/tmp/ftp$ ls -l folder1/
total 0
-rw-r--r-- 1 cktakahasi cktakahasi 0 2008-05-21 15:32 file1.txt
-rw-r--r-- 1 cktakahasi cktakahasi 0 2008-05-21 15:32 file2.txt

/* HCIDUMP indicates that ODS returned success */
> ACL data: handle 47 flags 0x02 dlen 35
    L2CAP(d): cid 0x0040 len 31 [psm 3]
      RFCOMM(d): UIH: cr 1 dlci 20 pf 0 ilen 27 fcs 0x31
        OBEX: Put cmd(f): len 27
        Connection ID (0xcb) = 1
        Name (0x01) = Unicode length 16
        0000: 00 66 00 6f 00 6c 00 64 00 65 00 72 00 31 00 00 .f.o.l.d.e.r.1..
< ACL data: handle 47 flags 0x02 dlen 11
    L2CAP(d): cid 0x004d len 7 [psm 3]
      RFCOMM(d): UIH: cr 0 dlci 20 pf 0 ilen 3 fcs 0xeb
        OBEX: Put rsp(f): status 200 len 3

skirsdeda

2008-05-28 16:45

Fixed in svn rev 1512 along with 0000085.

General

major

always

2008-05-21 19:57

2008-06-19 15:05

cktakahasi

larry

normal

closed

none

0.3.1

fixed

Crash on exit

There is a crash when the daemon exits. Pre-condition: one server active.

How Reproduce:
1. Start the ODS: $obex-data-server --no-daemon
2. create a server: $./obex-server-test.py opp /tmp
3. Press CRTL + C -- There is a segmentation fault when the daemon exits. See the log below:

** Message: me was killed
** Message: Disposing manager
** Message: server stopped
** Message: Default adapter
** Message: Disposing Server
** Message: Server disposed at once
** Message: server closed
** Message: Removing listened DBUS name :1.72 (object: /org/openobex/server0)
** Message: Removed from listened DBUS names list
** Message: Manager disposed
** Message: quitting main loop
==21297== Invalid read of size 4
==21297== at 0x409F624: g_hash_table_foreach (in /usr/lib/libglib-2.0.so.0.1600.3)
==21297== by 0x8050B37: ods_manager_dispose (ods-manager.c:819)
==21297== by 0x4045D6F: g_object_run_dispose (in /usr/lib/libgobject-2.0.so.0.1600.3)
==21297== by 0x804E6AA: sig_term (ods-main.c:52)
==21297== by 0x41BF127: (within /lib/tls/i686/cmov/libc-2.7.so)
==21297== by 0x40AFE7E: (within /usr/lib/libglib-2.0.so.0.1600.3)
==21297== by 0x40B01E6: g_main_loop_run (in /usr/lib/libglib-2.0.so.0.1600.3)
==21297== by 0x804EB77: main (ods-main.c:174)
==21297== Address 0x84 is not stack'd, malloc'd or (recently) free'd
==21297==
==21297== Process terminating with default action of signal 11 (SIGSEGV)
==21297== Access not within mapped region at address 0x84
==21297== at 0x409F624: g_hash_table_foreach (in /usr/lib/libglib-2.0.so.0.1600.3)
==21297== by 0x8050B37: ods_manager_dispose (ods-manager.c:819)
==21297== by 0x4045D6F: g_object_run_dispose (in /usr/lib/libgobject-2.0.so.0.1600.3)
==21297== by 0x804E6AA: sig_term (ods-main.c:52)
==21297== by 0x41BF127: (within /lib/tls/i686/cmov/libc-2.7.so)
==21297== by 0x40AFE7E: (within /usr/lib/libglib-2.0.so.0.1600.3)
==21297== by 0x40B01E6: g_main_loop_run (in /usr/lib/libglib-2.0.so.0.1600.3)
==21297== by 0x804EB77: main (ods-main.c:174)
==21297==
==21297== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 33 from 1)
==21297== malloc/free: in use at exit: 140,120 bytes in 650 blocks.
==21297== malloc/free: 3,362 allocs, 2,712 frees, 433,999 bytes allocated.
==21297== For counts of detected errors, rerun with: -v
==21297== searching for pointers to 650 not-freed blocks.
==21297== checked 272,004 bytes.
==21297==
==21297==
==21297== 800 bytes in 20 blocks are possibly lost in loss record 4 of 14
==21297== at 0x4021BDE: calloc (vg_replace_malloc.c:397)
==21297== by 0x40B49A4: g_malloc0 (in /usr/lib/libglib-2.0.so.0.1600.3)
==21297== by 0x405BF74: (within /usr/lib/libgobject-2.0.so.0.1600.3)
==21297== by 0x405C114: (within /usr/lib/libgobject-2.0.so.0.1600.3)
==21297== by 0x405EE3F: g_type_init_with_debug_flags (in /usr/lib/libgobject-2.0.so.0.1600.3)
==21297== by 0x405EFA1: g_type_init (in /usr/lib/libgobject-2.0.so.0.1600.3)
==21297== by 0x804E90E: main (ods-main.c:123)
==21297==
==21297==
==21297== 4,792 bytes in 9 blocks are possibly lost in loss record 10 of 14
==21297== at 0x4021A92: memalign (vg_replace_malloc.c:460)
==21297== by 0x4021B3F: posix_memalign (vg_replace_malloc.c:569)
==21297== by 0x40C9103: (within /usr/lib/libglib-2.0.so.0.1600.3)
==21297== by 0x40CA330: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.1600.3)
==21297== by 0x408750E: g_array_sized_new (in /usr/lib/libglib-2.0.so.0.1600.3)
==21297== by 0x4087616: g_array_new (in /usr/lib/libglib-2.0.so.0.1600.3)
==21297== by 0x40D539F: g_static_private_set (in /usr/lib/libglib-2.0.so.0.1600.3)
==21297== by 0x40DBDC0: g_get_charset (in /usr/lib/libglib-2.0.so.0.1600.3)
==21297== by 0x40B6B15: g_log_default_handler (in /usr/lib/libglib-2.0.so.0.1600.3)
==21297== by 0x40B5BFB: g_logv (in /usr/lib/libglib-2.0.so.0.1600.3)
==21297== by 0x40B5E88: g_log (in /usr/lib/libglib-2.0.so.0.1600.3)
==21297== by 0x804E978: main (ods-main.c:129)
==21297==
==21297== LEAK SUMMARY:
==21297== definitely lost: 0 bytes in 0 blocks.
==21297== possibly lost: 5,592 bytes in 29 blocks.
==21297== still reachable: 134,528 bytes in 621 blocks.
==21297== suppressed: 0 bytes in 0 blocks.
==21297== Reachable blocks (those to which a pointer was found) are not shown.
==21297== To see them, rerun with: --leak-check=full --show-reachable=yes
Segmentation fault

bug_83.patch (3 KB) 2008-05-26 20:16
bug83_cont.patch (3 KB) 2008-05-28 22:03

larry

2008-05-26 20:17

Proposed solution attached

skirsdeda

2008-05-27 17:03

Fixed in svn rev 1509.

larry

2008-05-28 20:35

More one situation for seg faut in exit
if I have one serversession open, I receive segmentation fault error in exits

skirsdeda

2008-05-28 20:59

It could be related to 0000074

larry

2008-05-28 22:04

new proposed solution for server_session exit error

skirsdeda

2008-05-29 00:07

Second patch included in svn rev 1513. Had to change some things. Check if things work as expected.

skirsdeda

2008-05-29 00:17

One small mistake fixed. svn rev 1514 should be good.

skirsdeda

2008-05-30 15:39

Tried playing with your newest patch (http://pastebin.com/m7d2a065d) [^] and it's still wrong. Try running server, then initiate server-session and kill obex-data-server in the middle of transfer. When you do so, server-session cancelling takes some time and server DISPOSED is emitted _BEFORE_ server-session is cancelled and disconnected, therefore I get this output:

** Message: me was killed
** Message: Disposing manager
** Message: server stopped
** Message: Default adapter
** Message: Disposing Server
** Message: attempting to close server session
** Message: server closed
** Message: Removing listened DBUS name :1.170 (object: /org/openobex/server0)
** Message: Removed from listened DBUS names list
** Message: Manager disposed
** Message: quitting main loop
** Message: Finalizing manager

Note that there are no lines like:
** Message: server session cancelled
** Message: server session closed

This is because server gets finalized earlier and it cannot receive signals, hence cannot call server_session_cancelled_cb or server_session_disconnected_cb.

skirsdeda

2008-05-30 15:58

Problems with current SVN code:
1) in server_session_disconnected_cb g_object_unref(server_session) doesn't finalize server_session. Reason might be that server_session is referenced somewhere else at that time and reference count doesn't become 0.

2) in server_session_disconnected_cb (g_hash_table_size (server->priv->session_list) == 0) check is incorrect. Since server_session disposal is asynchronous, session_list length here can be both 0 and 1. This is a matter of g_hash_table_foreach_remove finishing before or after last server_session_disconnected_cb, so when cancelling/disconnecting server_session takes more time session_list length will 0, otherwise 1.

skirsdeda

2008-05-30 21:22

Newest patch in svn rev 1518.

General

major

always

2008-03-26 12:29

2008-06-18 18:44

skirsdeda

normal

closed

none

0.3

fixed

auto_accept parameter in Server.start not respected in opp mode, always considered true

In OPP mode, whatever the value passed to the auto_accept parameter in Start on the Server hierarchy, ods behaves as if it was "True". So there is no way to accept/reject individual pushes.

Attached is a simple python piece of cade, which simply is a slightly modified version of odsserver.py. auto_accept = False, but pushes are always auto-accepted.

odserversimple.py (3 KB) 2008-03-26 12:29

skirsdeda

2008-03-26 12:54

It just doesn't work. This is a known bug. Will be fixed in 0.4.

2008-03-26 12:56

Ok, didn't find it in the BTS (did I miss it?) so I reported it.

skirsdeda

2008-03-26 12:59

It was hidden :) It's 0000054

skirsdeda

2008-05-12 23:09

0000054 updated.

General

major

always

2008-04-03 17:01

2008-05-14 04:21

iamer

skirsdeda

normal

closed

none

0.3.1

no change required

Cannot recieve files using bluetooth

I am trying to send files from a mobile phone ( N70 and W960i ) to my laptop using a usb dongle. The phone always complains "Failed to connect".

I remember this used to work when I had Gutsy and when i first upgraded to Hardy. I have all bluetooth related packages installed and updated, and using bluetooth-applet the laptop is discoverable and file receiving is enabled.

Expected :
Sent file should be received.

What happened :

obex-data-server is running and creates its dbus service fine. I can send things from the laptop to the mobile. I have hcidump of the failed connection mobile --> laptop.

HCI sniffer - Bluetooth packet analyzer ver 1.40
device: hci0 snap_len: 1028 filter: 0xffffffffffffffff
> HCI Event: Connect Request (0x04) plen 10
< HCI Command: Accept Connection Request (0x01|0x0009) plen 7
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Connect Complete (0x03) plen 11
< ACL data: handle 1 flags 0x02 dlen 10
    L2CAP(s): Info req: type 2
< HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
> HCI Event: Command Status (0x0f) plen 4
< HCI Command: Write Link Policy Settings (0x02|0x000d) plen 4
> HCI Event: Max Slots Change (0x1b) plen 3
> HCI Event: Command Complete (0x0e) plen 6
< HCI Command: Change Connection Packet Type (0x01|0x000f) plen 4
> HCI Event: Number of Completed Packets (0x13) plen 5
> ACL data: handle 1 flags 0x02 dlen 12
    L2CAP(s): Connect req: psm 1 scid 0x0040
> HCI Event: Command Status (0x0f) plen 4
< HCI Command: Remote Name Request (0x01|0x0019) plen 10
< ACL data: handle 1 flags 0x02 dlen 16
    L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0040 result 0 status 0
      Connection successful
> HCI Event: Connection Packet Type Changed (0x1d) plen 5
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Connection Packet Type Changed (0x1d) plen 5
> ACL data: handle 1 flags 0x02 dlen 16
    L2CAP(s): Info rsp: type 2 result 0
      Extended feature mask 0x0003
> HCI Event: Number of Completed Packets (0x13) plen 5
> HCI Event: Read Remote Supported Features (0x0b) plen 11
> ACL data: handle 1 flags 0x02 dlen 10
    L2CAP(s): Info req: type 2
< ACL data: handle 1 flags 0x02 dlen 16
    L2CAP(s): Info rsp: type 2 result 0
      Extended feature mask 0x0000
> ACL data: handle 1 flags 0x02 dlen 12
    L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 0
< ACL data: handle 1 flags 0x02 dlen 18
    L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 4
      Success
      MTU 672
< ACL data: handle 1 flags 0x02 dlen 12
    L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 0
> HCI Event: Number of Completed Packets (0x13) plen 5
> HCI Event: Remote Name Req Complete (0x07) plen 255
> HCI Event: Number of Completed Packets (0x13) plen 5
> HCI Event: Number of Completed Packets (0x13) plen 5
> ACL data: handle 1 flags 0x02 dlen 18
    L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 4
      Success
      MTU 672
> ACL data: handle 1 flags 0x02 dlen 17
    L2CAP(d): cid 0x0040 len 13 [psm 1]
        SDP SS Req: tid 0x1 len 0x8
          pat uuid-16 0x1105 (OBEXObjPush)
          max 65535
          cont 00
< ACL data: handle 1 flags 0x02 dlen 14
    L2CAP(d): cid 0x0040 len 10 [psm 1]
        SDP SS Rsp: tid 0x1 len 0x5
          count 0
          cont 00
> HCI Event: Number of Completed Packets (0x13) plen 5
> ACL data: handle 1 flags 0x02 dlen 12
    L2CAP(s): Disconn req: dcid 0x0040 scid 0x0040
< ACL data: handle 1 flags 0x02 dlen 12
    L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x0040
> HCI Event: Number of Completed Packets (0x13) plen 5
< HCI Command: Disconnect (0x01|0x0006) plen 3
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Disconn Complete (0x05) plen 4

I ran obex-data-server like this, and didn't get any useful messages :

obex-data-server --no-daemon
** Message: obex-data-server 0.3.1
** Message: Using Session bus
** Message: server socket created
** Message: Server created by: :1.5

** (obex-data-server:18583): WARNING **: Server path: /home/iamer/Desktop
** Message: Default adapter

iamer

2008-04-05 15:11

It seems to be a bug in latest bluez-utils package ... downgrading to bluez-utils_3.24-0ubuntu2_amd64.deb and using gnome-obex-server solves it.

General

major

always

2008-01-30 15:04

justinas

normal

new

none

open

Įmanoma sukurti link'ą su nuoroda į patį save.

To pasekoje tinklapis u

General

major

always

2007-02-03 00:50

2007-10-23 16:03

skirsdeda

normal

confirmed

none

open

Identifier sequencai veikia neoptimaliai

Nera suimplementuotas joks cache'inimo mechanizmas identifier'iu sequencams. Tarkim jei puslapyje yra 100 tokiu pachiu linku, tai bus daroma 100 DB queriu.

REIKIA perdaryti VirtualPage klase, kad cache'intu ishrezolvintus identifier'ius (ir galbut dar kazhka :)..

justinas

2007-10-23 16:03

Jau padarytas cachenimias Items i GLOBALS variable. reik nukopijuot sistema i VirtualPage klase.

General

major

always

2007-02-21 00:05

2007-10-23 16:02

skirsdeda

justinas

high

resolved

none

fixed

nepilnai sumerginti pakeitimai ish weblancet_db i weblancet trunk'a

Pvz nesumergintas patsai Component/DataStructure, indexbench.php ir matomai dar kiti dalykai.

Del shitos priezhasties prarasim branchu vienoduma, bo neimanoma mergint naujausiu pakeitimu i trunka.

justinas

2007-10-23 16:02

Viskas ten sumergeint'a, tik reikia vaikinius db branchus (lazerius ir t.t.) sumerdhzinti i trunka.

440

General

minor

have not tried

2010-04-26 12:08

justinas

normal

new

none

open

Neveikia vertimai su '

Nu tiesiog neveikia

215

General

minor

always

2009-10-22 04:02

2009-10-22 19:02

mikeyrb

skirsdeda

normal

resolved

none

0.4.5

fixed

USE_USB guards don't protect missing usb.h

Not entirely sure which package usb.h comes in, but in any case, I did configure with usb disabled and I get build errors because of usb.h. If you move '#ifdef USE_USB' above the includes (but below '#include "config.h"'), all is well.

This occurs in ods-usb.c and ods-usb.h.

skirsdeda

2009-10-22 19:02

Fixed in svn. Thanks for bug report.

161

General

minor

always

2009-03-23 21:10

2009-10-21 20:13

heston_james

skirsdeda

normal

closed

none

0.4.4

fixed

Access Denied when calling method.

Hi Tadas,

I'm recieving this error today when trying to use ODS on a newly built system, have you seen this error before? any suggestions on what might be causing it? I can connect and use BlueZ API's no problem at all.

I'm trying to roll this for a system which we're installing for the client on wednesday so need to get it fixed ASAP.

Many thanks mate,

Heston

Traceback (most recent call last):
  File "myapp.py", line 294, in <module>
    daemon.run()
  File "myapp.py", line 192, in run
    self.my_obex_manager = manager(bus, self.my_adapters, self.my_remote_devices)
  File "/myapp/src/model/obex/manager.py", line 64, in __init__
    self.__logger.info("Using obex-data-server version: %s" % self.__manager.GetVersion())
  File "/var/lib/python-support/python2.5/dbus/proxies.py", line 68, in __call__
    return self._proxy_method(*args, **keywords)
  File "/var/lib/python-support/python2.5/dbus/proxies.py", line 140, in __call__
    **keywords)
  File "/var/lib/python-support/python2.5/dbus/connection.py", line 607, in call_blocking
    message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 1 matched rules; type="method_call", sender=":1.2" (uid=0 pid=3798 comm="python myapp.py --no-daemon ") interface="org.openobex.Manager" member="GetVersion" error name="(unset)" requested_reply=0 destination=":1.1" (uid=0 pid=3797 comm="obex-data-server --no-daemon --system-bus "))

Org.OpenObex.tar.gz (23 KB) 2009-04-17 13:09

skirsdeda

2009-04-16 18:08

Can't really tell why this happens, maybe it's system specific. I haven't seen such error myself.

BTW, sorry for not answering for such a long time, I'm rather busy until june.

surfzoid

2009-04-17 13:09

Hi
Since now Mantis allow me to post i will report here some more info about this bug i have too :
From Monodevelop i have this short stackstrace, but can provide a more
complete one :
The session : /org/openobex/session0, get the stackstrace :
org.openobex.Error.ConnectionRefused, with error : Connection refused
HandleSessionClosed

From ods no-daemon i get :

[eric@SurfzoidPC obex-data-server-0.4.4]$ obex-data-server --no-daemon
** Message: obex-data-server 0.4.4
** Message: Using Session bus
** Message: Parsed[0]: ftp
** Message: FTP uuid selected, first checking for Nokia OBEX PC Suite
Services uuid
** Message: Connected SDP session
** Message: SDP search process
** Message: SDP search completed
** Message: no SDP records found
** Message: Using standard OBEX FTP uuid
** Message: SDP search process
** Message: SDP search completed
** Message: getting RFCOMM channel
** Message: Connect in progress
** Message: Failed to connect
** Message: session closed
** Message: Removing listened DBUS name :1.115 (object: /org/openobex/session0)
** Message: Removed from listened DBUS names list

There are other people in the same case and beleve it is a bluez problem :

http://forums.fedoraforum.org/showthread.php?t=207734 [^]

I attached one of my sample who use mono + gtk-sharp + ndesk-dbus, to connect to a remote bt device and list folder through obexftp

surfzoid

2009-04-17 14:17

Some other intersting info who make doub to say Bluez is the badboy,
My phone is corectly paired and trusted, when i start the bluetoothd daemon/service i see in syslog :
bluetoothd[14629]: probe failed with driver input-headset for device /org/bluez/14629/hci0/dev_00_16_20_C9_B4_B1

when i try to create btsession through ods i get the folowing error in syslog :

Apr 17 13:04:02 SurfzoidPC bluetooth: Starting hidd
Apr 17 13:04:03 SurfzoidPC obex-data-server: sdp_extract_seqtype: Unexpected end of packet
Apr 17 13:04:03 SurfzoidPC hidd[9952]: Bluetooth HID daemon
Apr 17 13:04:03 SurfzoidPC bluetoothd[2258]: link_key_request (sba=00:0A:3A:6D:57:B7, dba=00:16:20:C9:B4:B1)

then my sample get the conect refused error

now more interesting , if i try to create an USBsession i get the folowing syslog entry :

Apr 17 13:14:05 SurfzoidPC klogd: usb 4-4: usbfs: interface 1 claimed by cdc_acm while 'obex-data-serve' sets config 0000001

Imediatly my sample give the folowing error :

The session : /org/openobex/session13, get the stackstrace : org.openobex.Error.Failed, with error : USB setup failed

also i have same kind of error with obexftp, gnome-bluetooth, blueman ..

So can we conclude the problem came from openobex only, or it is a simple "hasard", since obexftp don't use ods.

skirsdeda

2009-04-17 14:25

What is the device you are trying to connect to and with what software it actually works?

surfzoid

2009-04-17 15:23

Bt and usb to a K750i SE phone, i'm the author of csobexftp and have it working in the past, but with my recent system, none software can connect

skirsdeda

2009-04-17 18:04

Unless you can prove otherwise, I consider this is you phone's fault. ods just reports to you that the device rejected connection.

surfzoid

2009-04-17 21:31

Nope, after a big clean of all obex, bluez, bluetooth file and rpm on my system, then just urpmi obex-data-server, i have a successfull session created, the problem with my sample is now, in your doc web page you say, "Dictionary<string, string> RetrieveFolderListing();" but if i look at your source code, the session xml file definition have a simple string.
So it was the doc or the XML the error ?

surfzoid

2009-04-17 21:32

I forget , at this time only USB not yet reinstalled and checked bluetooth

surfzoid

2009-04-17 22:55

Bluetooth also okay now, i have cleaned evry thingh to be sure , after the only diff is the result type of "RetrieveFolderListing()"

surfzoid

2009-04-18 23:46

The doc have always a dictionary as return type for RetrieveFolderListing, also to be lean, is there another cast problem in the doc ?

I looked at http://svn.muiline.com/obex-data-server/tags/REL-0_4_4/dbus-api.txt?view=co [^]

heston_james

2009-05-07 12:20

Tadas,

Back to the original problem I posted about; sorry for my late reply too, I've been away from work for a while. :-D I hope you're well?

This appears to be caused by a DBUS system.conf issue in the newer version of DBUS which is available on my apt repo, which is version 1.2.1-5. If I replace the system.conf with the one from version 1.2.1-3 then it appears to work just fine :-)

My guess that this is down to the new default security policy which comes with dbus, some changes perhaps need to be made to obex-data-server.conf to compensate for that?

This may well be a platform dependant thing, I'm running on Debian and perhaps the package maintainer has decided to mess around with the config file?

Cheers Tadas,

Heston

skirsdeda

2009-06-02 16:29

I updated obex-data-server.conf DBus config in svn. Can someone try and confirm that it works?

heston_james

2009-06-08 11:48

Tadas, I can confirm that this seems to work nicely! Thanks a great deal.

skirsdeda

2009-06-08 13:23

Great :)

158

FTP

minor

always

2009-02-14 13:39

2009-10-21 20:13

skirsdeda

normal

closed

none

0.4.4

fixed

Server does not support GET folder listing when using NAME header

FTP spec allows sending NAME header along with TYPE=x-obex/folder-listing. Name header specifies which folder to use without using SETPATH to go to that folder first.

skirsdeda

2009-02-14 22:44

Fixed in svn rev 2597.

111

General

minor

always

2008-07-25 14:50

2009-10-21 20:13

pwachend

skirsdeda

normal

closed

none

0.3.1

fixed

calling Method org.openobex.Session.Cancel() fails when org.openobex.Session.SendFile() is sending to Sony Ericsson mobiles

Hello,
I hope I'm right here.
I'm using rev 1656 of ods from svn.
org.openobex.Session.SendFile() ist started und trys to send data to my Sony Erricson Mobile over an OPP session.
If I don't accept/cancel the connection the Operation never get's an timeout.
Calling the session.Cancel() Method to stop the Sendjob fails with
DBusException: org.freedesktop.DBus.Error.NoReply

In the Additional Information is the output of obex-data-server --no-daemon while the pytonscript is running. The last ** Message: LOCK appearse after calling the Cancel() method of org.openobex.Session

Using an Nokia mobile Phone, I don't even need to call the Cancel() function,
because org.openobex.Error.ConnectionTimeout Error is droped after 30s.
It's seems that the differt implementations of OPP, are interrupting the send processes at differnt points for the user request.

Sorry for my bad english, Regards,
Paul

P.S.: where is the Connect() signal gone?

** Message: obex-data-server 0.4svn
** Message: Using Session bus
** Message: Parsed[0]: opp, Parsed[1]: 6
** Message: Connecting to 00:12:EE:58:72:1C using channel 6
** Message: Connect in progress
** Message: LOCK
** Message: UNLOCK
** Message: LOCK
** Message: UNLOCK
** Message: LOCK
** Message: UNLOCK
** Message: LOCK
** Message: UNLOCK
** Message: LOCK
** Message: UNLOCK
** Message: Connected
** Message: Session created by: :1.36
** Message: io callback
** Message: event: 3
** Message: obex_request_done: command 0, response OK, Success
** Message: LOCK
** Message: event: 8
** Message: obex_writestream
** Message: writestream from File: 7
** Message: event: 8
** Message: obex_writestream
** Message: writestream from File: 7
** Message: event: 0

** (obex-data-server:24366): WARNING **: PROGRESS: 7792
** Message: UNLOCK
** Message: LOCK

pwachend

2008-07-25 15:16

same behavior in rev 1674 (after bugfix for bug id 51) :-(

skirsdeda

2008-07-25 15:19

Thanks for bug report.
No real timeout mechanism is implemented in ods yet, although Cancel should not return DBus timeout. I'll look into that..

Connected signal is gone, because it was causing some race conditions. Now you have to use SessionConnected and SessionConnectError signals from Manager object.

pwachend

2008-10-07 17:06

in rev 1999 this problem is still persistent. Same behavior when calling SendFileExt(). Is it possible that these functions set some global lock, so that the Cancle() Function is waiting for its release instead of stopping the send process?

I thing a possibility to cancle an running send process would realy make sence.

heston_james

2008-10-07 17:22

Paul,

I think the reason this wasnt fixed by bug 51 is becuase bug 51 was designed to cancel the connection process to the phone.

With Nokia devices when you see the 'recieve data from someone?' message with accept or decline the RFCOMM connection has not yet been established, whereas, with Sony Ericson devices the RFCOMM connection is accepted automaticaly by the device and instead it haults and propts the user for acceptance of the file.

You're quite right though, the documentation states:

void Cancel()

Cancels any operation that is in progress.

So, the cancel should cancel the currently in progress file transmition.

Tadas, is this something we should perhaps consider as another one to be completed ready for 0.4?

Cheers,

Heston

pwachend

2008-10-08 14:18

Hi Heston,
I did a little closer look on this effect. It seem calling the Cancle() function allways produce an org.freedesktop.DBus.Error.NoReply Error after a longer timeout.
This happens on Sony Erricson and Nokia Phone when calling Cancel() on an connected session object.
The problem seems to have nothing to do with the ods_session_cancel and ods_session_cancel_internal functions in ods-session.c as the Error remains constant after commenting everything but "return True;" out.
Unfortunately my c is very rusty and I have no experience in c dbus programing (I'm connecting to the ods dbus-api over python), but if you can give me a little hint, where this timeout is rooted I'll try my best to fix this.

heston_james

2008-10-08 15:05

Hi Paul,

My C is pretty rusty too ;-) I'm a python man myself. Thats is very strange that you get the timeout even when the function isnt doing anything. My guess would be that the method is meant to be returning something which it isnt.

Let me take a little look at the source now and see if I can spot anything.

Paul, if you get chance, join us on the IRC channel.

Heston

heston_james

2008-10-08 15:19

Ok, taking a look at this now.

Like I say, my C is a little rusty but it looks as if the Cancel() methods should be asynchronous but its currently not set to return a value.

Whilst we're using "return True;" at the moment I believe this is only for the internal C methods and to have the actual dbus method return properly, and not cause the NoReply error we should be using something like:

dbus_g_method_return (context);
return TRUE;

If you look into the other asynchronous methods, such as SendFile() you'll notice that these all call the dbus_g_method_return() to make the method return immediatly.

Unfortunatly I dont have a system available to build ODS on here so I'm not able to patch and test but I would think that is where you need to be looking.

Heston

heston_james

2008-10-08 15:21

In addition, in cases where the cancel cannot be performed perhaps we need to use dbus_g_method_return_error (context, error); to return the error which occurred.

pwachend

2008-10-08 17:59

ok an kind of ugly hack is something like this:

diff ods-session.c ods-session.c.org:
2023,2024c2023,2024
< session->priv->state = ODS_SESSION_STATE_OPEN;
< g_signal_emit (session, signals[CANCELLED], 0);
---
> } else {
> ODS_SESSION_UNLOCK (session);
2026,2028d2025
<
< ODS_SESSION_UNLOCK (session);
< dbus_g_method_return(context);

this gives the possibility to cancel the send process... but isn't really satisfying.
I'll try to make a better fix when I understand dbus c programming a little bit better.

heston_james

2008-10-09 12:12

Paul,

Glad to see you made a little progress on this. Tell me, when you say 'but isn't really satisfying' what do you mean? What more are you trying to achieve other than canceling the send process?

Cheers,

Heston

skirsdeda

2008-10-09 20:39

I'm a little confused with this. This is how I understand what you are trying to do:
1) send a file using ods to a phone
2) don't do anything on the phone (neither accept, nor cancel)
3) call ods Session.Cancel function.
Is this correct?

Have in mind that what Cancel function does is interrupt OBEX request by sending CMD_ABORT command. If you don't accept/cancel transfer in remote device then that device is effectively blocking any OBEX data (hence it doesn't receive CMD_ABORT command).
The way how ods should act in such situation would be something like this:
1) When session is started, timeout callback would be added to mainloop
2) In timeout callback (which would be called in predefined time spans) we would check if no data was received from remote device during that time span. If so, session would be disconnected. And this is technically not CANCELLING but rather disconnecting because of a timeout, hence this bug (if I'm understanding it correctly) has nothing to do with Cancel function. It has to do with timeouts which are not yet implemented in ods since this is some tedious programming and it helps only in very uncommon situations.

Cheers,
Tadas

heston_james

2008-10-09 20:46

Tadas,

The issue I think Paul has been having here is that with a Sony Erricson and many Samsung handsets, when you call SendFile() we get a TransferStarted() signal emmited but the send process then hangs untill the user accepts the file on thier phone.

Paul wants to be able to call Cancel() on that transmition at this point and disconnect the session, whereas at the moment when trying to call disconnect it wont work because the session is 'busy'.

Does that make sense?

Heston

pwachend

2008-10-10 14:12

Right, thats the Problem. With the fix above It's possible to Call the Cancle() Function, but when calling Disconnect() after Cancle() an "org.openobex.Error.Busy: Another operation in progress" Error is dropped.

pwachend

2008-10-10 14:24

But I don't understand why this happens:
session->priv->state = ODS_SESSION_STATE_OPEN is set and the DBus Function session.IsBusy() return 0 (False) before Calling Disconnect().

Perhaps I'll find the Problem, when I've a little more time for this at the weekend. But I'd be very thankful, if you give me an other hint, where to search.

skirsdeda

2008-10-23 23:17

Could you attach your patch in a unified diff format please.

pwachend

2008-10-24 11:26

something like:

--- ods-session.c (revision 1999)
+++ ods-session.c (working copy)
@@ -2020,8 +2020,11 @@
                g_assert (!session->priv->dbus_context);
                session->priv->dbus_context = context;
                /* will return at obex_event{EV_ABORT} */
- } else {
- ODS_SESSION_UNLOCK (session);
+ session->priv->state = ODS_SESSION_STATE_OPEN;
+ g_signal_emit (session, signals[CANCELLED], 0);
        }
+
+ ODS_SESSION_UNLOCK (session);
+ dbus_g_method_return(context);
        return TRUE;
}

???

pwachend

2008-10-24 13:27

or for the newest svn version:

# diff -u ods-session.orginal ods-session.c
--- ods-session.orginal 2008-10-24 11:12:18.000000000 +0200
+++ ods-session.c 2008-10-24 11:17:55.000000000 +0200
@@ -2163,8 +2163,10 @@
                /* set dbus context */
                session->priv->dbus_context = context;
                /* will return at obex_event{EV_ABORT} */
- } else {
- ODS_SESSION_UNLOCK (session);
- }
+ session->priv->state = ODS_SESSION_STATE_OPEN;
+ g_signal_emit (session, signals[CANCELLED], 0);
+ }
+ ODS_SESSION_UNLOCK (session);
+ dbus_g_method_return(context);
        return TRUE;
}

skirsdeda

2008-11-29 17:07

This is now partly fixed in svn. Cancel will send a reply, however the actual cancelling won't happen. This will be completely fixed when I implement timeout mechanism in ods.

skirsdeda

2009-08-19 01:33

Implementation ideas for session timeout mechanism:
1. Add timeout at the end of ods_obex_send function
2. timeout (if any) has to be removed at the beginning of obex_event function
3. Add pointer to obex_event function into OdsObexContext struct
4. When timeout happens, it should call obex_event function with phony arguments (ABORT / RSP_TIMEOUT ?) and immediately disconnect underlying transport

server_session timeout mechanism:
when busy (ongoing put request), add timeout when waiting for STREAMAVAIL event. If timeout happens, RSP_TIMEOUT response should be sent to client, underlying transport should be disconnected and server_session finalized. In the beginning of STREAMAVAIL event timeout (if any) has to be removed.

skirsdeda

2009-08-22 21:09

session timeouts now implemented in subversion. Needs a lot of testing though.

206

General

minor

have not tried

2009-10-09 00:41

2009-10-21 20:13

skirsdeda

normal

closed

none

0.4.4

fixed

man page outdated

man page should be updated with new logging options and other stuff

172

General

minor

have not tried

2009-08-26 22:39

2009-10-21 20:13

skirsdeda

normal

closed

none

0.4.4

fixed

README file is empty

Fill in with basic info.

213

General

minor

have not tried

2009-10-18 16:49

2009-10-21 20:13

skirsdeda

normal

new

none

0.4.5

open

Check dbus service file when running in system bus

When running in system bus (ods -s), check dbus .service file on startup so that ods would have -s arg in .service file!