On 02/13/2017 08:51 AM, Lukas Slebodnik wrote:
On (13/02/17 08:38), Noriko Hosoi wrote:
On 02/12/2017 06:14 PM, William Brown wrote:
On Sun, 2017-02-12 at 17:42 -0800, Noriko Hosoi wrote:
On 02/12/2017 03:51 PM, Noriko Hosoi wrote:
https://pagure.io/389-ds-base/issue/49121
https://pagure.io/389-ds-base/issue/raw/files/d857ff4919940bcebeae870774896783f7b6e86ce08a2c2e924610ac2335f8de-0001-Ticket-49121-ns-slapd-crashes-in-ldif_sput-due-to-th.patch
These odd » characters are shown at some part of the patch. I wonder
what causes this display issue... And non-ascii characters are not
printed correctly although they are in the "View Raw" mode. Please
see the utf8str.txt file.
277 @@ -1499,30 +1506,36 @@ entry2str_internal_size_attrlist( const
Slapi_Attr *attrlist, int entry2str_ctrl
280 » » /* Count the space required for the present and deleted
values */
281 -» » elen+= entry2str_internal_size_valueset(a->a_type,
&a->a_present_values,
282 -» » » » » » » » » » » » entry2str_ctrl, attribute_state,
283 -» » » » » » » » » » » » VALUE_PRESENT); 305 +» » elen +=
entry2str_internal_size_valueset(a, a->a_type,
&a->a_present_values,
306 +» » entry2str_ctrl, attribute_state, VALUE_PRESENT);
Note: The test build was blessed by the bug reporter.
Thanks to William for his reviews. I've update the patch based on his
suggestion.
I also have 2 lib389 patches (attached to this email). Is lib389 still
in fedorahosted? I cloned pagure.io/lib389.git, but I found it empty...
1) could you please review the patches?
I'm happy with the dbscan change
I don't use the valgrind wrapper myself (it should disable transparently
when ASAN is enabled).
Are there any chance to support both valgrind and ASAN? Well, I'm not at the
position to insist anything any more here :p, but they are just tools and
supporting both of them is not a bad idea, is it?
FYI:
My experienceis that you should use either ASAN or valgrind.
They do not work well togeteher. That's the same for other sanitizers.
I see... Thanks, Lukas!
The current test scripts call valgrind APIs only if it's built without
ASAN enabled as follows. That is, if ASAN is enabled in the CI, the
valgrind check won't be executed. Probably, we could move this
"has_asan" check to the inside of the valgrind APIs and keep the APIs in
lib389?
*if not topology_m2.ms["master1"].has_asan():*
results_file = valgrind_get_results_file(topology_m2.ms["master1"])
Another question is, when the CI test enables ASAN, is this test case --
checking the valgrind result and determining the test case succeeded or
failed -- still valid? Or should we rewrite it based upon the ASAN
syntax (if any) later?
Thanks,
--noriko
ASAN is faster but valgrind should catch more bugs.
Of course it can change in future :-)
my 2 cents
LS
_______________________________________________
389-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
389-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
