On Wed, Feb 17, 2016 at 05:29:50PM +0100, Lukas Slebodnik wrote: > ehlo, > > simple patch is attached. > > I can reproduce it only with clang. > But it's typical off by one error. > > sh$ ./sss_idmap-tests > Running suite(s): IDMAP > Segmentation fault (core dumped) > > Running suite(s): IDMAP > ==2644== Process terminating with default action of signal 11 (SIGSEGV) > ==2644== Access not within mapped region at address 0xA08F430 > ==2644== at 0x4C2CC53: strcmp (vg_replace_strmem.c:842) > ==2644== by 0x4060DA: idmap_test_sid2uid_additional_secondary_slices > (sss_idmap-tests.c:451) > ==2644== by 0x503C78A: ??? (in /usr/lib64/libcheck.so.0.0.0) > ==2644== by 0x503CB7C: srunner_run (in /usr/lib64/libcheck.so.0.0.0) > ==2644== by 0x4061EE: main (sss_idmap-tests.c:965) > ==2644== If you believe this happened as a result of a stack > ==2644== overflow in your program's main thread (unlikely but > ==2644== possible), you can try to increase the size of the > ==2644== main thread stack using the --main-stacksize= flag. > ==2644== The main thread stack size used in this run was 8388608. > > LS
> From 10b1603e94a8785954f53b17f1e402b3019b29fa Mon Sep 17 00:00:00 2001 > From: Lukas Slebodnik <[email protected]> > Date: Wed, 17 Feb 2016 17:23:37 +0100 > Subject: [PATCH] sss_idmap-tests: Fix segmentation fault > > I can reproduce it only with clang. > But it's tipical off by one error. > > sh$ ./sss_idmap-tests > Running suite(s): IDMAP > Segmentation fault (core dumped) > > Running suite(s): IDMAP > ==2644== Process terminating with default action of signal 11 (SIGSEGV) > ==2644== Access not within mapped region at address 0xA08F430 > ==2644== at 0x4C2CC53: strcmp (vg_replace_strmem.c:842) > ==2644== by 0x4060DA: idmap_test_sid2uid_additional_secondary_slices > (sss_idmap-tests.c:451) > ==2644== by 0x503C78A: ??? (in /usr/lib64/libcheck.so.0.0.0) > ==2644== by 0x503CB7C: srunner_run (in /usr/lib64/libcheck.so.0.0.0) > ==2644== by 0x4061EE: main (sss_idmap-tests.c:965) > ==2644== If you believe this happened as a result of a stack > ==2644== overflow in your program's main thread (unlikely but > ==2644== possible), you can try to increase the size of the > ==2644== main thread stack using the --main-stacksize= flag. > ==2644== The main thread stack size used in this run was 8388608. > --- > src/tests/sss_idmap-tests.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/src/tests/sss_idmap-tests.c b/src/tests/sss_idmap-tests.c > index > 900b7bff1cd4f3c6f9cdffc4b012864d05e72913..885913645ed286636758f3f48a5a62d87cc9ab75 > 100644 > --- a/src/tests/sss_idmap-tests.c > +++ b/src/tests/sss_idmap-tests.c > @@ -427,8 +427,8 @@ START_TEST(idmap_test_sid2uid_additional_secondary_slices) > struct TALLOC_CTX *tmp_ctx; > const char *dom_prefix = "S-1-5-21-1-2-3"; > const int max_rid = 80; > - const char *sids[max_rid]; > - unsigned int ids[max_rid]; > + const char *sids[max_rid + 1]; > + unsigned int ids[max_rid + 1]; ACK. I'll add the CI link later for completeness. bye, Sumit > > tmp_ctx = talloc_new(NULL); > fail_unless(tmp_ctx != NULL, "Out of memory."); > -- > 2.5.0 > > _______________________________________________ > sssd-devel mailing list > [email protected] > https://lists.fedorahosted.org/admin/lists/[email protected] _______________________________________________ sssd-devel mailing list [email protected] https://lists.fedorahosted.org/admin/lists/[email protected]
