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

[henrik]

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.

[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.

[henrik]

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)

[dgollub]

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?

[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

[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

[dgollub]

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

[gillespie]

I can confirm this fixed with r4401

[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?

[felixmoeller]

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

[henrik]

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

[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.

[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.

[dgollub]

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

[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

[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

[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