http://bugzilla.moblin.org/show_bug.cgi?id=6457 --- Comment #2 from yongsheng zhu <yongsheng.zhu(a)intel.com&gt; 2009-09-27 18:16:16 --- funambol: CLIENT_TEST_SERVER=funambol CLIENT_TEST_SOURCES=vcard21,ical20,itodo20,text CLIENT_TEST_SKIP=Client::Sync::ical20::Retry,Client::Sync::ical20::Suspend,Client::Sync::ical20::Resend,Client::Sync::vcard21::Retry,Client::Sync::vcard21::Suspend,Client::Sync::vcard21::Resend,Client::Sync::itodo20::Retry,Client::Sync::itodo20::Suspend,Client::Sync::itodo20::Resend,Client::Sync::text::Retry,Client::Sync::text::Suspend,Client::Sync::text::Resend,Client::Sync::vcard21_ical20_itodo20_text::Retry,Client::Sync::vcard21_ical20_itodo20_text::Suspend,Client::Sync::vcard21_ical20_itodo20_text::Resend,Client::Sync::text_itodo20_ical20_vcard21::Retry,Client::Sync::text_itodo20_ical20_vcard21::Suspend,Client::Sync::text_itodo20_ical20_vcard21::Resend CLIENT_TEST_XML=1 CLIENT_TEST_MAX_ITEMSIZE=2048 CLIENT_TEST_DELAY=10 CLIENT_TEST_FAILURES= CLIENT_TEST_COMPARE_LOG=T CLIENT_TEST_RESEND_TIMEOUT=5 CLIENT_TEST_INTERRUPT_AT=1 SYNC_EVOLUTION_EVO_CALENDAR_DELAY=1 CLIENT_TEST_ALARM=1200 CLIENT_TEST_LOG= CLIENT_TEST_EVOLUTION_PREFIX=file:///work/runtests/head/databases schroot -p -c testing-amd64 -- /work/runtests/dbus-session.sh /work/runtests/valgrindcheck.sh env LD_LIBRARY_PATH=build-synthesis/src/.libs ./client-test Client::Sync: failed (return code 256) Do you mean this return code 256? If yes, we'll add it soon. -- Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching someone on the CC list of the bug.

http://bugzilla.moblin.org/show_bug.cgi?id=6457 --- Comment #4 from yongsheng zhu <yongsheng.zhu(a)intel.com&gt; 2009-09-28 19:02:39 --- the fix is done and should go into effect today. -- Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching someone on the CC list of the bug.

http://bugzilla.moblin.org/show_bug.cgi?id=6457 --- Comment #6 from yongsheng zhu <yongsheng.zhu(a)intel.com&gt; 2009-09-29 18:15:21 --- (In reply to comment #5) Here is the result from this text output: schroot -p -c testing-amd64 -- /work/runtests/dbus-session.sh /work/runtests/valgrindcheck.sh env LD_LIBRARY_PATH=build-synthesis/src/.libs ./client-test Client::Sync: failed (return code 256) I'll add it. strange. I could access it. The negative number is because Congwu made some changes on collecting all cases. we'll work this to solve it. thanks -- Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching someone on the CC list of the bug.

http://bugzilla.moblin.org/show_bug.cgi?id=6457 --- Comment #10 from yongsheng zhu <yongsheng.zhu(a)intel.com&gt; 2009-10-14 20:05:41 --- (In reply to comment #9) These should be done according to test results. -- Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching someone on the CC list of the bug.

http://bugzilla.moblin.org/show_bug.cgi?id=6457 --- Comment #12 from yongsheng zhu <yongsheng.zhu(a)intel.com&gt; 2009-10-18 22:44:51 --- On Unix, the return value of os.system() is the exit status of the process encoded in the format specified for os.wait(). For os.wait(),the return value is a 16-bit number, whose low byte is the signal number that killed the process, and whose high byte is the exit status (if the signal number is zero); Thus the return codes printed in the result are always multiples of 256 -- Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching someone on the CC list of the bug.

http://bugzilla.moblin.org/show_bug.cgi?id=6457 --- Comment #14 from yongsheng zhu <yongsheng.zhu(a)intel.com&gt; 2009-10-19 00:33:05 --- We have to add *too many* suppressions if using suppressions. But it seems to me harder to configure valgrind to only trace our binary. -- Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching someone on the CC list of the bug.

http://bugzilla.moblin.org/show_bug.cgi?id=6457 --- Comment #16 from pohly <patrick.ohly(a)intel.com&gt; 2009-10-20 00:53:17 --- (In reply to comment #14) How many errors did you find? Looking at tonight's "scheduleworld" run I see one error for /usr/lib/bonobo-activation/bonobo-activation-server and one for an unknown binary. Everything else is in SyncEvolution. "Everything" luckily isn't that much: one leak related to libical. This doesn't look that bad. What is more annoying is that multiple processes writing into the same valgrind file seem to add nul bytes to the file. This is visible when viewing with "less" and makes me wonder whether the output is really complete. So, here are two ideas how we can avoid this: * compile the "testing" binaries with --disable-shared --enable-static to avoid the libtool wrapper script, then stop using --trace-children=yes * run the bonobo-activation-server in advance, so that valgrind doesn't catch it I'll have a look at this. (In reply to comment #15) Is that a real problem for us or hypothetical? Tonight's run hasn't completed yet, but that isn't unusual. valgrind is a indeed a problem for CPU bound code, but we are mostly limited by IO performance and the obligatory sleeps() that we need to not overload servers and for the time-based change tracking. -- Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching someone on the CC list of the bug.

http://bugzilla.moblin.org/show_bug.cgi?id=6457 --- Comment #18 from yongsheng zhu <yongsheng.zhu(a)intel.com&gt; 2009-10-20 18:37:39 --- Yes, you are right. each 'interoperability server' has several error, some of them are the same. so I'll add them to the suppression file if they are not sync mem errors. scheduleword: 4 synthesis:11 funambol: 6 zyb:7 google: 7 mobical: 14 memotoo:12 -- Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching someone on the CC list of the bug.

http://bugzilla.moblin.org/show_bug.cgi?id=6457 --- Comment #20 from pohly <patrick.ohly(a)intel.com&gt; 2009-10-21 03:17:35 --- (In reply to comment #19) Careful here, please. For example, you added this one here: +# ==30565== 6,564 bytes in 144 blocks are definitely lost in loss record 48 of 72 +# ==30565== at 0x4C2391E: malloc (vg_replace_malloc.c:207) +# ==30565== by 0x5B1FA21: strdup (in /lib/libc-2.9.so) +# ==30565== by 0xD9E080C: icalparameter_new_from_value_string (in /usr/lib/libical.so.0.43.0) +# ==30565== by 0xD9F6AF0: icalparser_add_line (in /usr/lib/libical.so.0.43.0) +# ==30565== by 0xD9F7088: icalparser_parse (in /usr/lib/libical.so.0.43.0) +# ==30565== by 0xD9F7230: icalparser_parse_string (in /usr/lib/libical.so.0.43.0) +# ==30565== by 0xA2CB224: SyncEvo::EvolutionCalendarSource::insertItem(std::string const&, std::stri The suppression for it contains the full stack. That has the effect that the slightest change in how we call the function will no longer match the suppression, causing the error to pop up again. Other calls into icalparser_parse_string() are not matched by the suppression either. When adding a new suppression, think carefully about which stack entries to include in the match. In the example above, malloc strdup icalparameter_new_from_value_string would be much to broad. Including SyncEvolution as caller is too narrow. The right approach IMHO would be to identify the leak with icalparser_parse_string() as top-level call. Because it does not return the string which is leaked here, we can be reasonable sure that our code is not at fault. A similar problem occurs when specifying object files: obj:/usr/lib/libgnome-2.so.0.2600.0 This won't match anymore when the library version or install path changes. It's better to use wildcards: obj:*libgnome-2* As before, use common sense to choose between "too limited" and "too broad". All of the new suppressions should be reviewed taking that into account. However, perhaps we don't need them at all. I'm about to try out compiling with --disable-shared for valgrind testing. -- Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching someone on the CC list of the bug.

http://bugzilla.moblin.org/show_bug.cgi?id=6457 yongsheng zhu <yongsheng.zhu(a)intel.com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |yongsheng.zhu(a)intel.com --- Comment #22 from yongsheng zhu <yongsheng.zhu(a)intel.com&gt; 2009-10-21 18:24:41 --- Yes, reasonable. I'll refine the suppressions. -- Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching someone on the CC list of the bug.

http://bugzilla.moblin.org/show_bug.cgi?id=6457 --- Comment #24 from pohly <patrick.ohly(a)intel.com&gt; 2009-10-23 04:35:01 --- (In reply to comment #21) The whole run completed in 9 hours. This is fast enough to not overlap, but to be sure I added a check to runtests. It seems that someone has already enabled the cron job already. (In reply to comment #23) I removed them from the "nightly" branch. They are in bug6547-valgrind, so if we find that we need them, we can merge and refine them. -- Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching someone on the CC list of the bug.

http://bugzilla.moblin.org/show_bug.cgi?id=6457 ZhangJingke <jingke.zhang(a)intel.com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED CC| |jingke.zhang(a)intel.com Resolution| |MIGRATED --- Comment #26 from ZhangJingke <jingke.zhang(a)intel.com&gt; 2010-04-19 19:52:09 PST --- This issue is moved to http://bugzilla.meego.com/show_bug.cgi?id=1007 -- Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. You are watching someone on the CC list of the bug.