Menu
▾
▴
opensync-devel — The place to coordinate the development of OpenSync
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
(9) |
Apr
(84) |
May
(18) |
Jun
(12) |
Jul
(6) |
Aug
(7) |
Sep
(10) |
Oct
(31) |
Nov
(59) |
Dec
(14) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(53) |
Feb
(15) |
Mar
(43) |
Apr
(40) |
May
(63) |
Jun
(142) |
Jul
(54) |
Aug
(31) |
Sep
(30) |
Oct
(39) |
Nov
(36) |
Dec
(64) |
| 2007 |
Jan
(128) |
Feb
(261) |
Mar
(156) |
Apr
(127) |
May
(76) |
Jun
(131) |
Jul
(83) |
Aug
(124) |
Sep
(83) |
Oct
(88) |
Nov
(180) |
Dec
(90) |
| 2008 |
Jan
(86) |
Feb
(93) |
Mar
(117) |
Apr
(104) |
May
(65) |
Jun
(35) |
Jul
(38) |
Aug
(111) |
Sep
(58) |
Oct
(33) |
Nov
(102) |
Dec
(194) |
| 2009 |
Jan
(193) |
Feb
(74) |
Mar
(111) |
Apr
(77) |
May
(31) |
Jun
(20) |
Jul
(1) |
Aug
(3) |
Sep
(57) |
Oct
(125) |
Nov
(50) |
Dec
(3) |
| 2010 |
Jan
(26) |
Feb
(5) |
Mar
(13) |
Apr
(3) |
May
(3) |
Jun
(12) |
Jul
(27) |
Aug
(47) |
Sep
(105) |
Oct
(53) |
Nov
(34) |
Dec
(21) |
| 2011 |
Jan
(115) |
Feb
(17) |
Mar
|
Apr
(6) |
May
(16) |
Jun
(15) |
Jul
(85) |
Aug
(21) |
Sep
(13) |
Oct
(12) |
Nov
(28) |
Dec
(23) |
| 2012 |
Jan
|
Feb
(13) |
Mar
(4) |
Apr
|
May
(1) |
Jun
(5) |
Jul
(5) |
Aug
(31) |
Sep
(8) |
Oct
|
Nov
|
Dec
(1) |
| 2013 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(33) |
Sep
(9) |
Oct
(10) |
Nov
(2) |
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(4) |
| 2016 |
Jan
(2) |
Feb
|
Mar
(3) |
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: Chris F. <cd...@fo...> - 2011-07-23 10:30:01
|
On Sat, Jul 23, 2011 at 11:49:07AM +0200, Daniel Gollub wrote: > Unfortunately on my machine (openSUSE 11.4 - x86_64) still two tests fail: Thanks! I wonder if it has anything to do with 64bit? My machine is 32bit. > Maybe we should really switch as primary VCS to Git as base a clone > of your current repo? I'd be happy to push to another repo as well. That's the nice thing about git. We can push to many places. It would be nice to have an official spot on opensync.org to push to. My opensync-cdf repo has the 0.3x history from the 0.30 branch point to latest. There is a bit of history before that, which I didn't notice I missed at first. With the branches the way they are, it was hard to get git-svn to import them fully. So for history's sake, I think SVN should stick around, even with git taking over. My opensync-cdf repo also has a 'branch-0.2x' that contains the 0.22 history as well. That was tricky to grab all the 0.22 SVN branch commits, but I managed to pull all the important bits, to where I'm confident that the git repo has truly the latest of both opensync versions. I'm working to maintain both, with fixes and patches that I find. My binary-meta repo currently has its submodules configured to point to repo.or.cz, but that can be changed someday. The individual trees (lib, osynctool, and plugins) are not tied to any git site, and can be pushed anywhere, very easily. > Do you know if repo.cz or any other public repo allows to install customs hook? > I'm asking that so we can connect the git repo with trac. There is hook capability in git itself... if we ran our own server, that would definitely be possible. I don't think repo.or.cz supports it. Github seems to support some kind of JSON hook: http://help.github.com/post-receive-hooks/ Does that work with trac? - Chris |
|
From: Daniel G. <go...@b1...> - 2011-07-23 10:05:33
|
Valgrind output from the one which segfaults: On Saturday, July 23, 2011 11:49:07 AM Daniel Gollub wrote: [...] > Unfortunately on my machine (openSUSE 11.4 - x86_64) still two tests fail: > > ---8<-- > dgollub@marvin:~/projects/opensync-cdf/build> ctest -V -R > engine_error_get_changes_disconnect_error UpdateCTestConfiguration from > :/home/dgollub/projects/opensync-cdf/build/DartConfiguration.tcl Parse > Config > file:/home/dgollub/projects/opensync-cdf/build/DartConfiguration.tcl Add > coverage exclude regular expressions. > UpdateCTestConfiguration from > :/home/dgollub/projects/opensync-cdf/build/DartConfiguration.tcl Parse > Config > file:/home/dgollub/projects/opensync-cdf/build/DartConfiguration.tcl Test > project /home/dgollub/projects/opensync-cdf/build > Constructing a list of tests > Done constructing a list of tests > Checking test dependency graph... > test 152 > Start 152: engine_error_get_changes_disconnect_error > > 152: Test command: > /home/dgollub/projects/opensync-cdf/build/tests/engine-error > "engine_error_get_changes_disconnect_error" 152: Test timeout computed to > be: 1500 > 152: Running suite(s): "engine_error" > 152: 0%: Checks: 1, Failures: 0, Errors: 1 > 152: > /home/dgollub/projects/opensync-cdf/tests/support.c:436:E:engine_error_get > _changes_disconnect_error:function:0: (after this point) Received signal 11 > (Segmentation fault) > 1/1 Test #152: engine_error_get_changes_disconnect_error ...***Failed > 2.31 sec > > 0% tests passed, 1 tests failed out of 1 > > Total Test time (real) = 2.40 sec > > The following tests FAILED: > 152 - engine_error_get_changes_disconnect_error (Failed) > Errors while running CTest [...] > > I'll have closer look on them. Run with G_SLICE=always-malloc dgollub@marvin:~/projects/opensync-cdf/build/tests> valgrind /home/dgollub/projects/opensync-cdf/build/tests/engine-error engine_error_get_changes_disconnect_error ==490== Memcheck, a memory error detector ==490== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==490== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==490== Command: /home/dgollub/projects/opensync-cdf/build/tests/engine-error engine_error_get_changes_disconnect_error ==490== Running suite(s): "engine_error" ==491== Thread 4: ==491== Invalid write of size 4 ==491== at 0x4E7AF3D: osync_queue_disconnect (opensync_queue.c:1206) ==491== by 0x4E4E5FD: osyncClientDisconnectCallback (opensync_client.c:1960) ==491== by 0x50FBBD2: g_main_context_dispatch (in /lib64/libglib-2.0.so.0.2800.0) ==491== by 0x50FC3AF: ??? (in /lib64/libglib-2.0.so.0.2800.0) ==491== by 0x50FCA34: g_main_loop_run (in /lib64/libglib-2.0.so.0.2800.0) ==491== by 0x5123465: ??? (in /lib64/libglib-2.0.so.0.2800.0) ==491== by 0x749CA3E: start_thread (pthread_create.c:297) ==491== Address 0x7c9d228 is 232 bytes inside a block of size 240 free'd ==491== at 0x4C2599C: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==491== by 0x4E7A287: osync_queue_unref (opensync_queue.c:953) ==491== by 0x4E53D06: osync_client_proxy_shutdown (opensync_client_proxy.c:1239) ==491== by 0x4E5C421: _osync_engine_finalize_member (opensync_engine.c:749) ==491== by 0x4E5E3DD: osync_engine_finalize (opensync_engine.c:1807) ==491== by 0x4063F6: engine_error_get_changes_disconnect_error (check_engine_error.c:2907) ==491== by 0x6CEFE18: srunner_run_all (in /usr/lib64/libcheck.so.0.0.0) ==491== by 0x412548: osync_testsuite (support.c:65) ==491== by 0x6F11BFC: (below main) (libc-start.c:226) ==491== ==491== Invalid write of size 4 ==491== at 0x4E7AF3D: osync_queue_disconnect (opensync_queue.c:1206) ==491== by 0x4E4E63B: osyncClientDisconnectCallback (opensync_client.c:1969) ==491== by 0x50FBBD2: g_main_context_dispatch (in /lib64/libglib-2.0.so.0.2800.0) ==491== by 0x50FC3AF: ??? (in /lib64/libglib-2.0.so.0.2800.0) ==491== by 0x50FCA34: g_main_loop_run (in /lib64/libglib-2.0.so.0.2800.0) ==491== by 0x5123465: ??? (in /lib64/libglib-2.0.so.0.2800.0) ==491== by 0x749CA3E: start_thread (pthread_create.c:297) ==491== Address 0x7c9d848 is 232 bytes inside a block of size 240 free'd ==491== at 0x4C2599C: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==491== by 0x4E7A287: osync_queue_unref (opensync_queue.c:953) ==491== by 0x4E53CFD: osync_client_proxy_shutdown (opensync_client_proxy.c:1238) ==491== by 0x4E5C421: _osync_engine_finalize_member (opensync_engine.c:749) ==491== by 0x4E5E3DD: osync_engine_finalize (opensync_engine.c:1807) ==491== by 0x4063F6: engine_error_get_changes_disconnect_error (check_engine_error.c:2907) ==491== by 0x6CEFE18: srunner_run_all (in /usr/lib64/libcheck.so.0.0.0) ==491== by 0x412548: osync_testsuite (support.c:65) ==491== by 0x6F11BFC: (below main) (libc-start.c:226) ==491== ==491== Thread 15: ==491== Invalid read of size 4 ==491== at 0x50D1A32: g_atomic_int_exchange_and_add (in /lib64/libglib-2.0.so.0.2800.0) ==491== by 0x4E78A1D: osync_message_unref (opensync_message.c:60) ==491== by 0x4E7AD56: osync_queue_disconnect (opensync_queue.c:1161) ==491== by 0x4E4E700: _osync_client_hup_handler (opensync_client.c:1674) ==491== by 0x4E7969C: _incoming_dispatch (opensync_queue.c:392) ==491== by 0x50FBBD2: g_main_context_dispatch (in /lib64/libglib-2.0.so.0.2800.0) ==491== by 0x50FC3AF: ??? (in /lib64/libglib-2.0.so.0.2800.0) ==491== by 0x50FCA34: g_main_loop_run (in /lib64/libglib-2.0.so.0.2800.0) ==491== by 0x5123465: ??? (in /lib64/libglib-2.0.so.0.2800.0) ==491== by 0x749CA3E: start_thread (pthread_create.c:297) ==491== Address 0x8cbbec0 is 0 bytes inside a block of size 48 free'd ==491== at 0x4C2599C: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==491== by 0x4E7BA7F: _osync_send_timeout_response (opensync_queue.c:241) ==491== by 0x4E7AD41: osync_queue_disconnect (opensync_queue.c:1156) ==491== by 0x4E4E700: _osync_client_hup_handler (opensync_client.c:1674) ==491== by 0x4E7969C: _incoming_dispatch (opensync_queue.c:392) ==491== by 0x50FBBD2: g_main_context_dispatch (in /lib64/libglib-2.0.so.0.2800.0) ==491== by 0x50FC3AF: ??? (in /lib64/libglib-2.0.so.0.2800.0) ==491== by 0x50FCA34: g_main_loop_run (in /lib64/libglib-2.0.so.0.2800.0) ==491== by 0x5123465: ??? (in /lib64/libglib-2.0.so.0.2800.0) ==491== by 0x749CA3E: start_thread (pthread_create.c:297) ==491== Only in data1: testdata Only in data1: testdata ==491== ==491== HEAP SUMMARY: ==491== in use at exit: 74,166 bytes in 960 blocks ==491== total heap usage: 17,046 allocs, 16,086 frees, 4,610,261 bytes allocated ==491== ==491== LEAK SUMMARY: ==491== definitely lost: 184 bytes in 5 blocks ==491== indirectly lost: 3,996 bytes in 94 blocks ==491== possibly lost: 816 bytes in 3 blocks ==491== still reachable: 69,170 bytes in 858 blocks ==491== suppressed: 0 bytes in 0 blocks ==491== Rerun with --leak-check=full to see details of leaked memory ==491== ==491== For counts of detected and suppressed errors, rerun with: -v ==491== ERROR SUMMARY: 9 errors from 3 contexts (suppressed: 40 from 7) 100%: Checks: 1, Failures: 0, Errors: 0 /home/dgollub/projects/opensync-cdf/tests/engine-tests/check_engine_error.c:2911:P:engine_error_get_changes_disconnect_error:function:0: Passed ==490== ==490== HEAP SUMMARY: ==490== in use at exit: 0 bytes in 0 blocks ==490== total heap usage: 192 allocs, 192 frees, 42,839 bytes allocated ==490== ==490== All heap blocks were freed -- no leaks are possible ==490== ==490== For counts of detected and suppressed errors, rerun with: -v ==490== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4) dgollub@marvin:~/projects/opensync-cdf/build/tests> [...] Looks like wrong reference counting? Best Regards, Daniel -- Daniel Gollub Linux Consultant & Developer Tel.: +49-160 47 73 970 Mail: go...@b1... B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 |
|
From: Daniel G. <go...@b1...> - 2011-07-23 09:49:23
|
On Saturday, July 23, 2011 08:15:24 AM Chris Frey wrote:
> Hi folks,
>
> I did a test run on opensync tonight, using my git repo, and for the
> first time to my memory, in all my experience with opensync, all
> the tests pass for me.
Nice! Good job!
>
> Please let me know if you have different results.
Unfortunately on my machine (openSUSE 11.4 - x86_64) still two tests fail:
---8<--
dgollub@marvin:~/projects/opensync-cdf/build> ctest -V -R engine_error_get_changes_disconnect_error
UpdateCTestConfiguration from :/home/dgollub/projects/opensync-cdf/build/DartConfiguration.tcl
Parse Config file:/home/dgollub/projects/opensync-cdf/build/DartConfiguration.tcl
Add coverage exclude regular expressions.
UpdateCTestConfiguration from :/home/dgollub/projects/opensync-cdf/build/DartConfiguration.tcl
Parse Config file:/home/dgollub/projects/opensync-cdf/build/DartConfiguration.tcl
Test project /home/dgollub/projects/opensync-cdf/build
Constructing a list of tests
Done constructing a list of tests
Checking test dependency graph...
test 152
Start 152: engine_error_get_changes_disconnect_error
152: Test command: /home/dgollub/projects/opensync-cdf/build/tests/engine-error "engine_error_get_changes_disconnect_error"
152: Test timeout computed to be: 1500
152: Running suite(s): "engine_error"
152: 0%: Checks: 1, Failures: 0, Errors: 1
152: /home/dgollub/projects/opensync-cdf/tests/support.c:436:E:engine_error_get_changes_disconnect_error:function:0: (after this point)
Received signal 11 (Segmentation fault)
1/1 Test #152: engine_error_get_changes_disconnect_error ...***Failed 2.31 sec
0% tests passed, 1 tests failed out of 1
Total Test time (real) = 2.40 sec
The following tests FAILED:
152 - engine_error_get_changes_disconnect_error (Failed)
Errors while running CTest
dgollub@marvin:~/projects/opensync-cdf/build> ctest -V -R filter_destobjtype_delete
UpdateCTestConfiguration from :/home/dgollub/projects/opensync-cdf/build/DartConfiguration.tcl
Parse Config file:/home/dgollub/projects/opensync-cdf/build/DartConfiguration.tcl
Add coverage exclude regular expressions.
UpdateCTestConfiguration from :/home/dgollub/projects/opensync-cdf/build/DartConfiguration.tcl
Parse Config file:/home/dgollub/projects/opensync-cdf/build/DartConfiguration.tcl
Test project /home/dgollub/projects/opensync-cdf/build
Constructing a list of tests
Done constructing a list of tests
Checking test dependency graph...
test 39
Start 39: filter_destobjtype_delete
39: Test command: /home/dgollub/projects/opensync-cdf/build/tests/filter "filter_destobjtype_delete"
39: Test timeout computed to be: 1500
39: Running suite(s): "filter"
39: /home/dgollub/projects/opensync-cdf/tests/mock-plugin/mock_sync.c:95:E:mock_connect: Assertion "g_file_test(dir->path,
G_FILE_TEST_IS_DIR)" failed
39: 0%: Checks: 1, Failures: 0, Errors: 1
39: /home/dgollub/projects/opensync-cdf/tests/support.c:766:E:filter_destobjtype_delete:function:0: (after this point) Received signal 6
(Aborted)
1/1 Test #39: filter_destobjtype_delete ........***Failed 0.25 sec
0% tests passed, 1 tests failed out of 1
Total Test time (real) = 0.35 sec
The following tests FAILED:
39 - filter_destobjtype_delete (Failed)
Errors while running CTest
dgollub@marvin:~/projects/opensync-cdf/build>
--->8---
I'll have closer look on them.
[...]
Maybe we should really switch as primary VCS to Git as base a clone of your current repo?
Do you know if repo.cz or any other public repo allows to install customs hook?
I'm asking that so we can connect the git repo with trac.
Best Regards,
Daniel
--
Daniel Gollub
Linux Consultant & Developer
Tel.: +49-160 47 73 970
Mail: go...@b1...
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
|
|
From: Chris F. <cd...@fo...> - 2011-07-23 06:21:46
|
Hi folks, I did a test run on opensync tonight, using my git repo, and for the first time to my memory, in all my experience with opensync, all the tests pass for me. Please let me know if you have different results. It's been a long week of valgrind work, and repairing and debugging tests, but I'm pretty happy that I'm at this point already. This is not to say that all the tests are themselves accurate. I haven't gone through them and analyzed the logic. I just wanted the existing code to run and pass. Hopefully from now on, we can keep opensync in this good shape. And improve it. There are more corner cases, I'm sure, that valgrind can catch. The repo is here, with 65 commits over the past week and a half: http://repo.or.cz/w/opensync/opensync-cdf.git So far, all my tests have been with file-sync and mock-sync. Next on the agenda is to slowly work through the binary-meta tree, and test those plugins with valgrind as well. Hopefully opensync will become bulletproof soon. :-) Enjoy, - Chris git shortlog: Chris Frey (62): Minor code cleanup: use local variable instead of pointer again Added clarifying comments Merge remote branch 'luizluca/fix-memoryleak-serializer' Added explanatory comments for bit count totals in OSyncObjEngine Replaced bit twiddling code with simpler equivalents Fixed access of freed memory in osync_obj_engine_command() Fixed caps_converters and mergers memory leaks when freeing FormatEnv lists Fixed memory leak in osync_demarshal_objformatsink()'s error handling logic Fixed hairy OSyncList-based memory leak in osync_engine_initialize() Added note on debugging memory issues with valgrind doc: Added bird's eye view of the capabilities structure hierarchy Minor pointer initialization fix, and comment formatting Removed unused osync_capability_free() prototype Minor reorg of opensync_capability_private.h, and typo fix Comment typo No need to call a function to access internal struct value Fixed some of osync_capabilities_objtype_unref()'s cleanup logic Commented out unused prototype Added internal OSyncCapabilityParameter new/ref/unref API Changed capability list add behaviour API: changed osync_capability_new() API API: documented osync_capability_new_child() and _add_child() Added clarification comment to osync_capability_new_child() Added implementation for osync_capability_unref() API: changed osync_capabilities_objtype_new() to behave like _new() Updated osync_capabilities_objtype_parse doxygen comments Cleaned up osync_capabilities_unref() API: changed capability-related _parse() and _parse_and_add() functions API: reorganized capabilities API to be more consistent and clear leak: fixed two leaks in osync_member_support_targetformat() memory: fixed potential invalid memory access in error case of osync_demarshal_pluginconfig() leak: fixed invalid use of osync_free(), should have used osync_plugin_config_unref() leak: fixed leak in osync_message_new() in the error case leak: fixed ref logic error in _osync_queue_generate_error() Added proper child support to OSyncError Fixed trace logging in new capabilities functions Fixed typo in osync_engine_get_cmdstr() Fixed logic of unidirectional write optimization in osync_obj_engine_command() leak: fixed osync_list_free() bug in _inject_changelog_entries leak: fixed missing calls to osync_db_free_list() doc: added What is the difference between _private.h and _internal.h headers? Changed engine's busy flag to volatile leak: fixed leaks in the xmlformat and xmlfield API doc: clarified freeing responsibility for osync_format_env_find_path_with_detectors() leak: fixed extremely tricky set of leaks in osync_format_env_find_path_fn() leak: fixed potential leaks in the error path of osync_demarshal_change() leak: fixed leaked change object in _osync_client_handle_read_change() leak: fixed leaked change and data objects in _inject_changelog_entries() leak: fixed leak in osync_archive_get_mixed_objengines() leak: fixed leak and logic error in _osync_client_proxy_fin_handler() leak: fixed leak in osync_queue_disconnect(), and tightened up locking API: osync_xmlformat_assemble() now returns osync_strdup() buffer doc: clarify how osync_xmlformat_assemble() buffer should be freed Fixed path name bug in test data test: added workaround for the empty directory problem with git Fixed comment typo test: beefed up error checking for system() calls Fixed unref on pointer before checking if valid (oops) Added basic error logging in osync_member_support_targetformat() leak: fixed ref leak in mock_initialize Added OSYNC_ERROR_MAX error type, for error type range checking Added error type range check in osync_demarshal_error(), and log if out of range Luiz Angelo Daros de Luca (3): - formatting stuff - Fix memoryleak. objformat is duplicated and must be freed. - Fix memory leak when some error occurs in osync_demarshal_objtype_sink - Fix memory leak in osync_demarshal_objtype_sinks as it never unrefs sinks |
|
From: Chris F. <cd...@fo...> - 2011-07-22 22:52:26
|
Hi Daniel, While fixing leaks, I ran across the following function in the xmlformat plugin: http://repo.or.cz/w/opensync/xmlformat-cdf.git/commitdiff/d6bf4461281d96bfeb4bc593a087c04c6e232d3f I've removed all the dead code (which contained a leak), but while it looks correct, and the sync continues to work without that dead code, it looks kinda odd. I just wanted to confirm: is is true that the duplicate callback is only for duplicating the UID? Why is there an output/outsize mechanism involved in that case? How else can the duplicate callback be used? Thanks! - Chris |
|
From: Chris F. <cd...@fo...> - 2011-07-22 22:46:58
|
Hi, I've made a memory allocation change to the function osync_xmlformat_assemble() which can be viewed here: http://repo.or.cz/w/opensync/opensync-cdf.git/commitdiff/b80405e0eafb0cebf1c034d9f08ceff778bf4fe3 Much of the code that I've seen, both inside the library and in the plugins, assumes that the resulting buffer from a call to osync_xmlformat_assemble() can be freed with osync_free() or g_free(). But the call passes back memory that expects to be freed with libxml2's xmlFree(). If you're on a system that uses malloc everywhere, this might not matter, but glib/gtk uses its own g_slice memory management, and this might cause problems. With the above commit, osync_xmlformat_assemble() gives back an osync_strdup() buffer, so freeing works as expected. scriptor: I've noticed in your ldap plugin code, you free this memory with calls to xmlFree(), which is very correct, but plugins shouldn't have to know this. This change will affect you. Also, I notice that you make much use of valgrind in your testing. I've been fixing a lot of memory leaks in opensync in the above git repo. If you'd like to give it a try and report back if you see any improvement, that would be great. - Chris |
|
From: Michael B. <mic...@cm...> - 2011-07-19 08:08:21
|
Hi, I planned to support OMA DM to configure mobiles for SyncML (OMA DS). The problem is that the specification only defines the structure but not the semantics. If you want to use it then you must implement a lot of vendor specific stuff. The final answer is: Yes, there was a plan but the plan is gone (since May 2009). Sorry Michael P.S. I can forward an internal mail from May 2009 with the full explanation. On 07/18/11 19:06, James Hanley wrote: > There was mention on the roadmap of the wiki that there was some effort > and interest for device management - has there been any work, and are > there any working reference code for showing the capability. > > > > ------------------------------------------------------------------------------ > AppSumo Presents a FREE Video for the SourceForge Community by Eric > Ries, the creator of the Lean Startup Methodology on "Lean Startup > Secrets Revealed." This video shows you how to validate your ideas, > optimize your ideas and identify your business strategy. > http://p.sf.net/sfu/appsumosfdev2dev > > > > _______________________________________________ > Opensync-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensync-devel -- ___________________________________________________________________ Michael Bell Humboldt-Universitaet zu Berlin Tel.: +49 (0)30-2093 70143 ZE Computer- und Medienservice Fax: +49 (0)30-2093 70135 Unter den Linden 6 mic...@cm... D-10099 Berlin ___________________________________________________________________ PGP Fingerprint: 09E4 3D29 4156 2774 0F2C C643 D8BD 1918 2030 5AAB |
|
From: Chris F. <cd...@fo...> - 2011-07-18 21:40:55
|
Hi, I've made a number of changes and fixed some memory leaks in the capabilities API. You can see the last change here: http://repo.or.cz/w/opensync/opensync-cdf.git/commitdiff/a826a3ce69bd1e84beca7344c18e2a0047306960 I've updated the evolution2, vformat, and xmlformat plugins as well, with the small API change required, since I'm tracking them. For plugin authors, the change is pretty simple: Change: osync_capability_new() To: osync_capabilities_add_new_capability() and Change: osync_capabilities_objtype_new() To: osync_capabilieis_add_new_objtype() The reason for this change was because the capabilities API behaved differently than the rest of opensync. The _new() calls would add the new object to an internal list, and return an unref'd pointer. This is inconsistent with what the user will expect from every other _new() call in the library. Also, due to this oddity, some of the internal implementations were very difficult to get right. While building the capabiities hierarchy, there could be errors after an object was created, but before it could be returned successfully. I have changed the internal API so that all calls to _new(), _ref(), and _unref(), in the capabilities API behave as expected. I have also hidden a number of calls, in favour of promoting just the top level OSyncCapabilities objects. This is all that the user should need to worry about, when it comes to memory management, and the normal _new(), _ref(), and _unref() calls are available for it only. API Changes: ============ Removed (moved to internal) osync_capabilities_objtype_new osync_capabilities_objtype_ref osync_capabilities_objtype_unref osync_capability_new osync_capability_ref osync_capability_unref Added osync_capabilities_add_new_objtype osync_capabilities_add_new_capability Background: =========== For those who don't know what the "capabilities hierarchy" is, here's the docs that I added to opensync_capabilities_private.h. /** * @brief Represent a Capabilities object * * This is the top level Capabilities object, which contains a list of * lists of capability objects for each objtype. * * For example, if your device has a set of capabilities, you could call the * set "foodevice-caps". This would be the Capabilities format name. * This format name could contain different capability lists for each * objtype supported, for example "contact" or "event" or both. * * The names of the capabilities do not have to match anything else, but * if they do not match something opensync knows about, it will need a * caps-converter (capabilities converter) to translate your list of * capability objects for, say, "contact" into something it knows, say, * "xmlformat-contact". * * foodevice-caps * contact * name * address1 * phonenumber * event * date * location * * I don't know if multiple objtypes are ever useful, but they are possible, * given the 3 structures: OSyncCapabilities, OSyncCapabilitiesObjType, * and finally OSyncCapability. * * Note that OSyncCapability is a hierarchical list, having its own children. * It also has a list of OSyncCapabilityParameter objects. * */ The Capabilities API could use some feedback and thought. Currently there is no way to properly manage the OSyncCapabilityParameters programmatically. Enjoy, - Chris |
|
From: Chris F. <cd...@fo...> - 2011-07-18 17:19:08
|
On Mon, Jul 18, 2011 at 01:57:14PM +0100, Ian Martin wrote: > I think the point was that opensync didn't export glib data types in > its api. So whilst you need glib-dev to build opensync you dont need > it to build a library/program/plugin using opensync. So the use of > glib is encapsulated within opensync. That would certainly make sense. Thanks! - Chris |
|
From: James H. <jh...@dg...> - 2011-07-18 17:06:47
|
There was mention on the roadmap of the wiki that there was some effort and interest for device management - has there been any work, and are there any working reference code for showing the capability. |
|
From: Ian M. <ian...@ca...> - 2011-07-18 12:57:20
|
>I'm not fully sure why, but I do know that there was a migration away >from the glist stuff, to osync_list code. Most of the time it is a >wrapper around glibc, but some of the list code appears to be copied. > Daniel: do you have some historical reasons to explain the above? I think the point was that opensync didn't export glib data types in its api. So whilst you need glib-dev to build opensync you dont need it to build a library/program/plugin using opensync. So the use of glib is encapsulated within opensync. As to the importance/usefulness and the reason behind this choice I don't know. Ian |
|
From: Chris F. <cd...@fo...> - 2011-07-18 06:14:45
|
On Mon, Jul 18, 2011 at 02:44:03AM -0300, Luiz Angelo Daros de Luca wrote: > BTW, file-sync uses glist instead of osync_list. If glibc is already a > dependency, why opensync need osync_list? Is one of them "legacy"? I'm not fully sure why, but I do know that there was a migration away from the glist stuff, to osync_list code. Most of the time it is a wrapper around glibc, but some of the list code appears to be copied. In general, the opensync code and plugins should be using osync_list functions, where possible. But if your code is independent from opensync, you're free to use glist. Some opensync calls return OSyncList objects, and they should be freed with osync_list_free(). Daniel: do you have some historical reasons to explain the above? - Chris |
|
From: Chris F. <cd...@fo...> - 2011-07-18 06:11:55
|
On Mon, Jul 18, 2011 at 02:44:03AM -0300, Luiz Angelo Daros de Luca wrote: > Hello, > > Here goes the patch > > git://github.com/luizluca/file-sync-luizluca.git > > bug-env_not_used > bug_double-random > bugs-fixed (both previous fixes) Thanks! Merged bugs-fixed, along with a small typo fix. - Chris |
|
From: Luiz A. D. de L. <lui...@gm...> - 2011-07-18 05:54:44
|
Now it builds :-)
---
Luiz Angelo Daros de Luca, Me.
lui...@gm...
2011/7/17 Chris Frey <cd...@fo...>
> On Sun, Jul 17, 2011 at 08:37:52PM -0300, Luiz Angelo Daros de Luca wrote:
> > Just for curiosity, this is what a file-sync is like when written in
> > ruby. It is almost line-by-line identical to C version. As script
> languages
> > are more expressive, it uses almost the half number of line and a lot of
> > less pressed keys.
> >
> >
> https://github.com/luizluca/libopensync-plugin-ruby/blob/proposed/example/ruby-file-sync.rb
>
> Nifty!
>
>
> > Now, about your current work: binary-meta.
>
> First of all, thanks for testing!
>
>
> > It fails at this point:
> >
> > $ make deb-fs-latest
> > (...)
> > dh_installmenu
> > dh_install
> >
> --sourcedir=/mnt/usuarios/luizluca/prog/opensync/binary-meta/debian/opensync-latest/debian/tmp
> > --fail-missing
> > dh_install: python-opensync missing files
> > (usr/lib/python*/site-packages/opensync.py), aborting
> > make[2]: ** [binary-common] Erro 2
> > make[2]: Saindo do diret??rio
> > `/mnt/usuarios/luizluca/prog/opensync/binary-meta/debian/opensync-latest'
> > make[1]: ** [binary-arch] Erro 2
> > make[1]: Saindo do diret??rio
> > `/mnt/usuarios/luizluca/prog/opensync/binary-meta/debian/opensync-latest'
> > make: ** [deb-os-latest-build] Erro 2
>
> Whoops, that's just a packaging error. The files are supposed to
> go into dist-packages on debian anyway. I've fixed the latest git.
>
> Please note that I'm currently grinding my way through the opensync
> library, rescuing widows and orphans as I may... er, fixing memory leaks
> and memory access errors reported by valgrind. It is a work in progress,
> and afterward, opensync will be better, but reducing memory leaks always
> raises the risk of doing a double free somewhere before I find it in
> the next valgrind run. Just a caution. :-)
>
> Opensync certainly needs the TLC... :-)
>
>
> > Also, why is it needed that opensync must not be installed in my system
> > before the build? It checks for installed version using pkgconfig. For a
> > distribution maintainer, what generally occurs is exactly the opposite:
> each
> > package that is required for build should be installed in the build
> system
> > before it is built.
>
> Yeah, that's just to avoid potential conflicts. I haven't tested the
> makefile while having libopensync binary packages installed, yet. I
> suppose
> it should work in theory, since PKG_CONFIG_PATH and LD_LIBRARY_PATH and
> friends should take precedence, but so far it's enough work getting
> all these packages wrangled into order without tackling the corner
> cases. :-)
>
> You're welcome to try it. I suspect it will work, but no guarantees.
>
> And you're right... the binary-meta package is intended to be different.
> It is supposed to making building opensync binary packages extremely
> easy on any machine, without root. i.e. create a new user on your system,
> drop in binary-meta, and instant binary package build system. The
> dependency install scripts take care of the distro stuff, and the
> makefile takes care of the rest.
>
> There are also new targets now for building source-only, without the
> binary packages. You can even set the PREFIX and DESTDIR on a tree-wide
> scale. See the README-devel.txt file for details.
>
>
> > I guess that a unified build would be interesting for the developers, as
> it
> > can test api breakage for all plugins at once. Does binary-meta run
> tests?
>
> Not yet. But that's a good idea... I've added it to my todo list.
>
> Thanks,
> - Chris
>
>
>
> ------------------------------------------------------------------------------
> AppSumo Presents a FREE Video for the SourceForge Community by Eric
> Ries, the creator of the Lean Startup Methodology on "Lean Startup
> Secrets Revealed." This video shows you how to validate your ideas,
> optimize your ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
> _______________________________________________
> Opensync-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensync-devel
>
|
|
From: Luiz A. D. de L. <lui...@gm...> - 2011-07-18 05:44:34
|
Hello, Here goes the patch git://github.com/luizluca/file-sync-luizluca.git bug-env_not_used bug_double-random bugs-fixed (both previous fixes) BTW, file-sync uses glist instead of osync_list. If glibc is already a dependency, why opensync need osync_list? Is one of them "legacy"? --- Luiz Angelo Daros de Luca, Me. lui...@gm... 2011/7/18 Luiz Angelo Daros de Luca <lui...@gm...> > Maybe not that much safe. :-) If I remove it, I will introduce a new memory > leak. The sink data will never get freed on plugin_destroy. So, currently, > there is this memory leak. > > > --- > Luiz Angelo Daros de Luca, Me. > lui...@gm... > > > 2011/7/17 Chris Frey <cd...@fo...> > >> On Sun, Jul 17, 2011 at 09:28:36PM -0300, Luiz Angelo Daros de Luca wrote: >> > osync_filesync_report_dir and the get_changes are sink stuff and >> receives >> > the sink data, not the plugin data. The env (plugindata) is only >> referenced >> > in initialize and finalize. However, as the first does not fill it, it >> is >> > useless for finalize. >> >> Yeah. I don't think *directories is used anywhere at all, >> so it's probably safe to remove. >> >> - Chris >> >> >> >> ------------------------------------------------------------------------------ >> AppSumo Presents a FREE Video for the SourceForge Community by Eric >> Ries, the creator of the Lean Startup Methodology on "Lean Startup >> Secrets Revealed." This video shows you how to validate your ideas, >> optimize your ideas and identify your business strategy. >> http://p.sf.net/sfu/appsumosfdev2dev >> _______________________________________________ >> Opensync-devel mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/opensync-devel >> > > |
|
From: Luiz A. D. de L. <lui...@gm...> - 2011-07-18 04:53:04
|
Maybe not that much safe. :-) If I remove it, I will introduce a new memory
leak. The sink data will never get freed on plugin_destroy. So, currently,
there is this memory leak.
---
Luiz Angelo Daros de Luca, Me.
lui...@gm...
2011/7/17 Chris Frey <cd...@fo...>
> On Sun, Jul 17, 2011 at 09:28:36PM -0300, Luiz Angelo Daros de Luca wrote:
> > osync_filesync_report_dir and the get_changes are sink stuff and receives
> > the sink data, not the plugin data. The env (plugindata) is only
> referenced
> > in initialize and finalize. However, as the first does not fill it, it is
> > useless for finalize.
>
> Yeah. I don't think *directories is used anywhere at all,
> so it's probably safe to remove.
>
> - Chris
>
>
>
> ------------------------------------------------------------------------------
> AppSumo Presents a FREE Video for the SourceForge Community by Eric
> Ries, the creator of the Lean Startup Methodology on "Lean Startup
> Secrets Revealed." This video shows you how to validate your ideas,
> optimize your ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
> _______________________________________________
> Opensync-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensync-devel
>
|
|
From: Chris F. <cd...@fo...> - 2011-07-18 01:04:49
|
On Sun, Jul 17, 2011 at 08:37:52PM -0300, Luiz Angelo Daros de Luca wrote: > Just for curiosity, this is what a file-sync is like when written in > ruby. It is almost line-by-line identical to C version. As script languages > are more expressive, it uses almost the half number of line and a lot of > less pressed keys. > > https://github.com/luizluca/libopensync-plugin-ruby/blob/proposed/example/ruby-file-sync.rb Nifty! > Now, about your current work: binary-meta. First of all, thanks for testing! > It fails at this point: > > $ make deb-fs-latest > (...) > dh_installmenu > dh_install > --sourcedir=/mnt/usuarios/luizluca/prog/opensync/binary-meta/debian/opensync-latest/debian/tmp > --fail-missing > dh_install: python-opensync missing files > (usr/lib/python*/site-packages/opensync.py), aborting > make[2]: ** [binary-common] Erro 2 > make[2]: Saindo do diret??rio > `/mnt/usuarios/luizluca/prog/opensync/binary-meta/debian/opensync-latest' > make[1]: ** [binary-arch] Erro 2 > make[1]: Saindo do diret??rio > `/mnt/usuarios/luizluca/prog/opensync/binary-meta/debian/opensync-latest' > make: ** [deb-os-latest-build] Erro 2 Whoops, that's just a packaging error. The files are supposed to go into dist-packages on debian anyway. I've fixed the latest git. Please note that I'm currently grinding my way through the opensync library, rescuing widows and orphans as I may... er, fixing memory leaks and memory access errors reported by valgrind. It is a work in progress, and afterward, opensync will be better, but reducing memory leaks always raises the risk of doing a double free somewhere before I find it in the next valgrind run. Just a caution. :-) Opensync certainly needs the TLC... :-) > Also, why is it needed that opensync must not be installed in my system > before the build? It checks for installed version using pkgconfig. For a > distribution maintainer, what generally occurs is exactly the opposite: each > package that is required for build should be installed in the build system > before it is built. Yeah, that's just to avoid potential conflicts. I haven't tested the makefile while having libopensync binary packages installed, yet. I suppose it should work in theory, since PKG_CONFIG_PATH and LD_LIBRARY_PATH and friends should take precedence, but so far it's enough work getting all these packages wrangled into order without tackling the corner cases. :-) You're welcome to try it. I suspect it will work, but no guarantees. And you're right... the binary-meta package is intended to be different. It is supposed to making building opensync binary packages extremely easy on any machine, without root. i.e. create a new user on your system, drop in binary-meta, and instant binary package build system. The dependency install scripts take care of the distro stuff, and the makefile takes care of the rest. There are also new targets now for building source-only, without the binary packages. You can even set the PREFIX and DESTDIR on a tree-wide scale. See the README-devel.txt file for details. > I guess that a unified build would be interesting for the developers, as it > can test api breakage for all plugins at once. Does binary-meta run tests? Not yet. But that's a good idea... I've added it to my todo list. Thanks, - Chris |
|
From: Chris F. <cd...@fo...> - 2011-07-18 00:31:31
|
On Sun, Jul 17, 2011 at 09:28:36PM -0300, Luiz Angelo Daros de Luca wrote: > osync_filesync_report_dir and the get_changes are sink stuff and receives > the sink data, not the plugin data. The env (plugindata) is only referenced > in initialize and finalize. However, as the first does not fill it, it is > useless for finalize. Yeah. I don't think *directories is used anywhere at all, so it's probably safe to remove. - Chris |
|
From: Chris F. <cd...@fo...> - 2011-07-18 00:29:34
|
On Sun, Jul 17, 2011 at 09:20:24PM -0300, Luiz Angelo Daros de Luca wrote: > This one might not be a bug. I might be wrong but let's see: > > Still in file-sync module/src/file_sync.c at get_sync_info: > > If some error occurs, it calls: > > osync_error_unref(error); > > However, error was not allocated here. It is passed as argument. If it is an > argument, probably the caller wishes to know if an error occurs and it also > responsible to free it. I guess no function that receives "OSyncError > **error" refs it (osync_error_ref(error)) or unrefs it. So, the result, I > guess, is that, if some error happens, error is freed inside get_sync_info > and the caller will never know. Even worse if the caller wishes to deref it, > it will segfalts. The error is reported in the osync_trace(), so the file_sync author probably figured that was enough error handling for a plugin load failure. :-) It is valid either way. The error objects are special, since it is safe to unref a NULL pointer, and unrefing a valid error will change the pointer to NULL, so that future calls won't balk. In other words, this is safe: OSyncError *error = NULL; osync_error_unref(&error); Not all unrefs behave that way, only error, since you don't know where in the call stack the error will be handled. - Chris |
|
From: Luiz A. D. de L. <lui...@gm...> - 2011-07-18 00:29:02
|
2011/7/17 Chris Frey <cd...@fo...> > On Sun, Jul 17, 2011 at 09:06:15PM -0300, Luiz Angelo Daros de Luca wrote: > > I don't know it the bug tracker at the site is still valid so I'm writing > > about the bug I found to the list. > > I like bug reports to the mailing list, actually. > > > > Correct me if I'm wrong. > > > > File-sync/src/file-sync.c at osync_filesync_initialize: > > > > "OSyncFileEnv *env" is initialized with no problem. It contains only a > list > > of "GList *directories". However, this list is never filled. > > At the end of each sink loop, it should add dir to env->directories. The > > result is that free_env never frees dirs as > > it has no reference for them. > > I'm not sure, but it looks like a leftover from earlier designs. > It seems that the directories are recursed in the get_changes stage, > with a call to osync_filesync_report_dir(). > > osync_filesync_report_dir and the get_changes are sink stuff and receives the sink data, not the plugin data. The env (plugindata) is only referenced in initialize and finalize. However, as the first does not fill it, it is useless for finalize. > > > > File-sync/src/file.c at conv_plain_to_file: > > > > file->path = osync_rand_str(g_random_int_range(1, 100), error); > > > > the g_random_int_range(1, 100) returns a random number between 1 and 100. > > However, the osync_rand_str already does this. Its first argument is "int > > maxlength", which is used in: > > > > length = g_random_int_range(1, maxlength + 1); > > > > Seems to be a double random :-). It should be enough to call: > > > > file->path = osync_rand_str(100, error); > > That's pretty funky. :-) Yes, your assessment looks correct to me. > > I'm not sure why a random length filename is desired here though. > And if it is, I'm not sure why a maxlength of 1 is desirable. > > If this is an attempt to avoid filename clashes, it seems a little weak, > no? > > Thanks for catching these... want to cook up some patches? :-) > I'll try to do it in my next free time hour. > > - Chris > > > > ------------------------------------------------------------------------------ > AppSumo Presents a FREE Video for the SourceForge Community by Eric > Ries, the creator of the Lean Startup Methodology on "Lean Startup > Secrets Revealed." This video shows you how to validate your ideas, > optimize your ideas and identify your business strategy. > http://p.sf.net/sfu/appsumosfdev2dev > _______________________________________________ > Opensync-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensync-devel > --- Luiz Angelo Daros de Luca, Me. lui...@gm... |
|
From: Chris F. <cd...@fo...> - 2011-07-18 00:21:43
|
On Sun, Jul 17, 2011 at 09:06:15PM -0300, Luiz Angelo Daros de Luca wrote: > I don't know it the bug tracker at the site is still valid so I'm writing > about the bug I found to the list. I like bug reports to the mailing list, actually. > Correct me if I'm wrong. > > File-sync/src/file-sync.c at osync_filesync_initialize: > > "OSyncFileEnv *env" is initialized with no problem. It contains only a list > of "GList *directories". However, this list is never filled. > At the end of each sink loop, it should add dir to env->directories. The > result is that free_env never frees dirs as > it has no reference for them. I'm not sure, but it looks like a leftover from earlier designs. It seems that the directories are recursed in the get_changes stage, with a call to osync_filesync_report_dir(). > File-sync/src/file.c at conv_plain_to_file: > > file->path = osync_rand_str(g_random_int_range(1, 100), error); > > the g_random_int_range(1, 100) returns a random number between 1 and 100. > However, the osync_rand_str already does this. Its first argument is "int > maxlength", which is used in: > > length = g_random_int_range(1, maxlength + 1); > > Seems to be a double random :-). It should be enough to call: > > file->path = osync_rand_str(100, error); That's pretty funky. :-) Yes, your assessment looks correct to me. I'm not sure why a random length filename is desired here though. And if it is, I'm not sure why a maxlength of 1 is desirable. If this is an attempt to avoid filename clashes, it seems a little weak, no? Thanks for catching these... want to cook up some patches? :-) - Chris |
|
From: Luiz A. D. de L. <lui...@gm...> - 2011-07-18 00:20:51
|
This one might not be a bug. I might be wrong but let's see:
Still in file-sync module/src/file_sync.c at get_sync_info:
If some error occurs, it calls:
osync_error_unref(error);
However, error was not allocated here. It is passed as argument. If it is an
argument, probably the caller wishes to know if an error occurs and it also
responsible to free it. I guess no function that receives "OSyncError
**error" refs it (osync_error_ref(error)) or unrefs it. So, the result, I
guess, is that, if some error happens, error is freed inside get_sync_info
and the caller will never know. Even worse if the caller wishes to deref it,
it will segfalts.
Regards,
---
Luiz Angelo Daros de Luca, Me.
lui...@gm...
2011/7/17 Luiz Angelo Daros de Luca <lui...@gm...>
> Hello,
>
> I don't know it the bug tracker at the site is still valid so I'm writing
> about the bug I found to the list.
> Correct me if I'm wrong.
>
> File-sync/src/file-sync.c at osync_filesync_initialize:
>
> "OSyncFileEnv *env" is initialized with no problem. It contains only a list
> of "GList *directories". However, this list is never filled.
> At the end of each sink loop, it should add dir to env->directories. The
> result is that free_env never frees dirs as
> it has no reference for them.
>
>
> File-sync/src/file.c at conv_plain_to_file:
>
> file->path = osync_rand_str(g_random_int_range(1, 100), error);
>
> the g_random_int_range(1, 100) returns a random number between 1 and 100.
> However, the osync_rand_str already does this. Its first argument is "int
> maxlength", which is used in:
>
> length = g_random_int_range(1, maxlength + 1);
>
> Seems to be a double random :-). It should be enough to call:
>
> file->path = osync_rand_str(100, error);
>
>
> Regards,
>
> ---
> Luiz Angelo Daros de Luca, Me.
> lui...@gm...
>
|
|
From: Luiz A. D. de L. <lui...@gm...> - 2011-07-18 00:06:41
|
Hello,
I don't know it the bug tracker at the site is still valid so I'm writing
about the bug I found to the list.
Correct me if I'm wrong.
File-sync/src/file-sync.c at osync_filesync_initialize:
"OSyncFileEnv *env" is initialized with no problem. It contains only a list
of "GList *directories". However, this list is never filled.
At the end of each sink loop, it should add dir to env->directories. The
result is that free_env never frees dirs as
it has no reference for them.
File-sync/src/file.c at conv_plain_to_file:
file->path = osync_rand_str(g_random_int_range(1, 100), error);
the g_random_int_range(1, 100) returns a random number between 1 and 100.
However, the osync_rand_str already does this. Its first argument is "int
maxlength", which is used in:
length = g_random_int_range(1, maxlength + 1);
Seems to be a double random :-). It should be enough to call:
file->path = osync_rand_str(100, error);
Regards,
---
Luiz Angelo Daros de Luca, Me.
lui...@gm...
|
|
From: Luiz A. D. de L. <lui...@gm...> - 2011-07-17 23:38:18
|
Hello Chris, Now I guess my ruby-module is, let's say, very playable. My original objective was lost at the second day of development (I lost my old cellphone with was not supported by opensync). Anyway, I continued to write it. It took more time than I though at first because the Ruby MRI (also called CRuby) is not designed to be embedded, specially, it is not thread-safe. I had to use some hacks with stack and threads in order to make it work. Just for curiosity, this is what a file-sync is like when written in ruby. It is almost line-by-line identical to C version. As script languages are more expressive, it uses almost the half number of line and a lot of less pressed keys. https://github.com/luizluca/libopensync-plugin-ruby/blob/proposed/example/ruby-file-sync.rb This does not currently work with opensync master as I changed some api ;-). However, this is a topic for another time. Now, about your current work: binary-meta. It fails at this point: $ make deb-fs-latest (...) dh_installmenu dh_install --sourcedir=/mnt/usuarios/luizluca/prog/opensync/binary-meta/debian/opensync-latest/debian/tmp --fail-missing dh_install: python-opensync missing files (usr/lib/python*/site-packages/opensync.py), aborting make[2]: ** [binary-common] Erro 2 make[2]: Saindo do diretório `/mnt/usuarios/luizluca/prog/opensync/binary-meta/debian/opensync-latest' make[1]: ** [binary-arch] Erro 2 make[1]: Saindo do diretório `/mnt/usuarios/luizluca/prog/opensync/binary-meta/debian/opensync-latest' make: ** [deb-os-latest-build] Erro 2 And what I have: $ ls /mnt/usuarios/luizluca/prog/opensync/binary-meta/debian/opensync-latest/debian/tmp/usr/lib/python2.7/ dist-packages There is no site-packages. I know nothing about python file structure and I wish I could help more here. Also, why is it needed that opensync must not be installed in my system before the build? It checks for installed version using pkgconfig. For a distribution maintainer, what generally occurs is exactly the opposite: each package that is required for build should be installed in the build system before it is built. I guess that a unified build would be interesting for the developers, as it can test api breakage for all plugins at once. Does binary-meta run tests? Regards, --- Luiz Angelo Daros de Luca, Me. lui...@gm... 2011/7/7 Chris Frey <cd...@fo...> > On Thu, Jul 07, 2011 at 11:31:54AM -0400, Chris Frey wrote: > > > I am sure that my patch will break modules. I'll fix and post some > > > patch for them. I guess I will need to commit individually for each > > > submodule, isn't it? And I will have to create github repos for each > > > of them in order to publish my commit... > > > > Yep. :-) That would be helpful. > > > > Is it relatively easy to create github repos? Alternatively, if you > > post your patches to the mailing list without utf-8, or maybe just attach > > them instead of including them inline, that might work as well. > > I find that the opensync project is rather large and unwieldy at times. > I'm still trying to find the best way to manage the whole thing. If you > have suggestions along the way, please don't hesitate to let me know. > > With all the plugins and dependencies, the "getting started" work is > pretty high. binary-meta helps a little, but not enough, I think. > > So far, binary-meta only does binary packages, which is not that useful > for development. I hope to add makefile targets to build everything > as source, so that devs can treat the whole tree as one big source tree, > too. > > - Chris > > |
|
From: Chris F. <cd...@fo...> - 2011-07-16 01:47:24
|
Hi Daniel, I've been working on opensync memory leaks, and found an interesting one in the FormatEnv unref code: http://repo.or.cz/w/opensync/opensync-cdf.git/commitdiff/9fcebe4abc933e256fa65bfbb2c1f4936c3966ff For caps_converters, it looks like it is possible to have init/final logic in the format plugins, since these functions exist: osync_caps_converter_set_initialize_func() osync_caps_converter_set_finalize_func() osync_caps_converter_initialize() osync_caps_converter_finalize() The FormatEnv code does not seem to make use of any of these calls, so my memory leak patch above does not call finalize(). The merger code on the other hand, only has the following functions in opensync_merger.c: osync_merger_set_initialize_func() osync_merger_set_finalize_func() There are no functions available to call these callbacks. Could you give me a bird's eye overview of how the caps_converters and mergers are supposed to work from an API point of view? Should I be implementing init/final sequences in FormatEnv for both? Or is there a reason FormatEnv doesn't bother with these? Thanks! - Chris |
90 messages has been excluded from this view by a project administrator.
