Ticket #1003 (new defect)

Opened 5 years ago

Last modified 4 years ago

infinite loop when trying to sync with syncml-obex-client

Reported by: henrik Owned by:
Priority: high Milestone:
Component: Plugin: syncml-client Version: 0.38
Severity: critical Keywords:
Cc: henrik@…

Description

Build out of SVN:

  • OPENSYNC_REL="4474"
  • LIBSYNCML_REL="854"
  • LIBWBXML_REL="142"

Synchronizing freshly created groups with a Nokia 6280

  • group2: syncml-obex-client vs file-sync
  • group3: syncml-obex-client vs mozilla-sync

In both cases, osynctool goes into an infinite loop.

Attachments

GROUP_2.zip (4.0 KB) - added by henrik 5 years ago.
OSYNC_TRACE_2.zip (510.1 KB) - added by henrik 5 years ago.
GROUP_3.zip (4.6 KB) - added by henrik 5 years ago.
OSYNC_TRACE_3.zip (4.3 MB) - added by henrik 5 years ago.
T5.zip (105.9 KB) - added by henrik 5 years ago.

Change History

Changed 5 years ago by henrik

Changed 5 years ago by henrik

Changed 5 years ago by henrik

Changed 5 years ago by henrik

comment:1 follow-up: ↓ 3 Changed 5 years ago by felixmoeller

I guess this is a major regression. I am experiencing it with "syncml-obex-client vs file-sync".

It was working a week or two ago.

comment:2 Changed 5 years ago by henrik

  • Priority changed from normal to high
  • Severity changed from normal to critical

Good to hear that this is reproducible.

As suggested by Daniel, I have tried to let it run for more than 30 minutes. After 50 minutes and 3,6G of logfiles, I killed it ))-:

Another interesting observation:

If I run with the exact same group configuration, but *without* OSYNC_TRACE and SYNCML_TRACE, I get:

contact sink of member 1 of type syncml-obex-client had an error: An internal I/O error occured. Not found (0x44)

comment:3 in reply to: ↑ 1 Changed 5 years ago by dgollub

  • Summary changed from Infinite loop when trying to sync with syncml-obex-client to [NEEDINFO] Infinite loop when trying to sync with syncml-obex-client

Replying to felixmoeller:

I guess this is a major regression. I am experiencing it with "syncml-obex-client vs file-sync".

It was working a week or two ago.

What are last known to work SVN revisions?

Henrik, which log files crowed to 3.6G? The SYNCML_TRACE ones, or the OSYNC_TRACE ones?

comment:4 Changed 5 years ago by henrik

I have not tried with this phone for a long time, so I cannot identify last working SVN revision.

It is the SYNCML logfile which grows with millions of this:

[1230481040.143690]             smlSessionCheck: status is missing - 1
[1230481040.143735]             >>>>>>>  smlSessionTryLock(0xb3e01ad8)
[1230481040.143777]             <<<<<<<  smlSessionTryLock - 0

comment:5 Changed 5 years ago by felixmoeller

syncml-ds-tool still works perfectly for me.

I am right now at:

libsyncml2-0.5.0_SVN874-1.1
libopensync-plugin-vformat-0.38_SVN4487-2.1
libopensync1-0.38_SVN4487-1.1
libopensync-tools-0.38_SVN4487-1.1
libopensync-plugin-syncml-0.38_SVN4487-1.1
libsyncml-tools-0.5.0_SVN874-1.1
libopensync-ipc-0.38_SVN4487-1.1
osynctool-0.38_SVN4487-1.1
libopensync-plugin-file-0.38_SVN4487-1.1

Sadly I do not have revision numbers of my last working checkout.

It was certainly after:

------------------------------------------------------------------------
r4326 | bellmich | 2008-12-11 13:27:22 +0100 (Do, 11. Dez 2008) | 2 lines

added support for ActiveConnection

;)

I can confirm henriks observation, my logs get filled with:

[1230806910.471185]             smlSessionCheck: status is missing - 1
[1230806910.471228]             >>>>>>>  smlSessionTryLock(0x8174870)
[1230806910.471270]             <<<<<<<  smlSessionTryLock - 0
[1230806910.471313]             smlSessionCheck: status is missing - 1
[1230806910.471355]             >>>>>>>  smlSessionTryLock(0x8174870)
[1230806910.471398]             <<<<<<<  smlSessionTryLock - 0
[1230806910.471441]             smlSessionCheck: status is missing - 1
[1230806910.471483]             >>>>>>>  smlSessionTryLock(0x8174870)
[1230806910.471526]             <<<<<<<  smlSessionTryLock - 0

comment:6 Changed 5 years ago by dgollub

Could you please try r4401 (to make sure this got broken with r4438).

comment:7 follow-up: ↓ 8 Changed 5 years ago by gillespie

I can confirm this fixed with r4401

comment:8 in reply to: ↑ 7 Changed 5 years ago by dgollub

Replying to gillespie:

I can confirm this fixed with r4401

This also means it's broken with latest revision of the SyncML plugin. Falling back to r4401, will also loose the late-"SlowSync?" support Henrik requested few weeks ago. I'll have a look at that later... very likely for some reason the g_cond_signal() never gets send for certain circumstances or there is just a ugly race.

Felix and Henrik, could you validate that we're talking here about the same issue?

comment:9 Changed 5 years ago by felixmoeller

  • Summary changed from [NEEDINFO] Infinite loop when trying to sync with syncml-obex-client to infinite loop when trying to sync with syncml-obex-client

I downgraded to libopensync-plugin-syncml-0.38_SVN4401 (r4401) leaving everything else the same and now it works ...

comment:10 follow-up: ↓ 11 Changed 5 years ago by henrik

I can try -r4401, but which version of libsyncml do you want me to use? -r828 ?

comment:11 in reply to: ↑ 10 Changed 5 years ago by dgollub

Replying to henrik:

I can try -r4401, but which version of libsyncml do you want me to use? -r828 ?

Latest - or what ever you want this issue should be independent of the libsyncml version.

comment:12 follow-up: ↓ 13 Changed 5 years ago by henrik

Building with

  • OPENSYNC_REL="4401"
  • LIBSYNCML_REL="828"
  • LIBWBXML_REL="142"

I get

Not found (0x44)
contact sink of member 1 of type syncml-obex-client had an error: An internal I/O error occured.

and then Segmentation fault.

Traces attached.

Changed 5 years ago by henrik

comment:13 in reply to: ↑ 12 ; follow-up: ↓ 14 Changed 5 years ago by dgollub

  • Owner changed from bellmich to dgollub
  • Status changed from new to assigned

Replying to henrik:

Building with

  • OPENSYNC_REL="4401"
  • LIBSYNCML_REL="828"
  • LIBWBXML_REL="142"

I get

Not found (0x44)
contact sink of member 1 of type syncml-obex-client had an error: An internal I/O error occured.

and then Segmentation fault.

Traces attached.

Without checking the traces, i would say this is another issue then the infinite loop. Could you file for this a seperated ticket to not mix-up the infinite-loop/hang issue with the 0x44 issue?

Could you please provide in the new ticket the command line you use for syncml-ds-tool, which is known to work, and your syncml plugin configuration which seems not work?

I'm still quite certain that "inifinite-loop" issue is due to the "late-SlowSync?"-implementation with r4401

comment:14 in reply to: ↑ 13 Changed 5 years ago by dgollub

Replying to dgollub:

I'm still quite certain that "inifinite-loop" issue is due to the "late-SlowSync?"-implementation with r4401

Ooops - i mean r4438

comment:15 Changed 5 years ago by henrik

I would not like to file a bug against this "old" version. I agree that the segfault may be another issue altogether. I would suggest that when #1003 is fixed, I will try again. If the segfault issue remains, I will file a new ticket. OK? /Henrik

comment:16 Changed 5 years ago by dgollub

  • Milestone OpenSync 0.39 deleted

comment:17 Changed 4 years ago by dgollub

  • Owner dgollub deleted
  • Status changed from assigned to new

comment:18 Changed 4 years ago by sim

decoration Changed 1 year ago by admin

bathtub Changed 1 year ago by admin

solar system Changed 1 year ago by admin

stair parts Changed 1 year ago by admin

solar supply Changed 1 year ago by admin

Note: See TracTickets for help on using tickets.