[389-devel] Re: csiphash on Sparc
On 11.10.17 10:54, William Brown <wibr...@redhat.com> wrote:
>
> On Tue, 2017-10-10 at 16:28 +0200, Carsten Grzemba wrote:
> >
> > On 10.10.17 16:10, William Brown <wibr...@redhat.com> wrote:
> > >
> > > On Fri, 2017-10-06 at 10:21 +0200, Carsten Grzemba wrote:
> > > > Currently the code src/libsds/external/csiphash/csiphash.c do not work
> > > > on Sparc.
> > > > The casting void* or char* to unit64_t* throws Bus-Error.
> > > >
> > > > The solution would be to copy the content of the void and char pointer
> > > > so that the variabeles are suitably aligned.
> > > > To prevent have to use malloc: do we know the max of src_sz?
> > > >
> > >
> > >
> > > What line is this? I assume you are refering to:
> > >
> > > https://pagure.io/389-ds-base/blob/master/f/src/libsds/external/csiphash/csiphash.c#_82
> > >
> > yes!
> >
> > >
> > > (https://pagure.io/389-ds-base/blob/master/f/src/libsds/external/csiphash/csiphash.c#_82)
> > >
> > > No, we can't know the max of src_sz, in theory it could be uint64_t max.
> > > So this may not be an option.
> > >
> > So is malloc for uint64 alignment of the src variable the only option?
> >
> > >
> > >
> > >
> > > Are you trying this on a 32bit platform perhaps? What's the arch of the
> > > machine with the issue?
> > >
> > 64bit, Fujitsu M4000
> > $ isainfo -v
> > 64-bit sparcv9 applications
> > fmaf vis2 vis popc
>
> I feel like there is something I'm missing here in the problem. What is
> sizeof(void *) on this platform? I'm assuming 4 or 16 rather than 8
> bytes? Is this correct?
>
no it is 8.
The following programm works on x86 but dumps on Sparc:
#include
#include
int func(const void *str, size_t sz, const char key[16]){
uint64_t *ip = (uint64_t*) str;
printf ("str: %lx:%lx\n", ip, *ip);
}
int main()
{
char str[25] = "ABCDEFGH12345678";
char key[16];
printf ("sizeof void* %d\n", sizeof(void*));
printf ("sizeof char* %d\n", sizeof(char*));
printf ("sizeof uint64_t* %d\n", sizeof(uint64_t*));
func(str, 12, key);
func([1], 11, key);
}
On x86:
grzemba@unstable11x:~/Tests$ gcc -g -m64 -O3 -fPIC -DPIC -MD -MP size_test.c -o
st_x86
grzemba@unstable11x:~/Tests$ ./st_x86
sizeof void* 8
sizeof char* 8
sizeof uint64_t* 8
str: 80ffbb20:4847464544434241
str: 80ffbb21:3148474645444342
On Sparc:
grzemba@unstable11s:~/Tests$ gcc -g -m64 -O3 -fPIC -DPIC -MD -MP size_test.c -o
st_sparc
grzemba@unstable11s:~/Tests$ ./st_sparc
sizeof void* 8
sizeof char* 8
sizeof uint64_t* 8
str: 77d0:4142434445464748
Bus Error (core dumped)
grzemba@unstable11s:~/Tests$ gdb st_sparc core
GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.11".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/grzemba/Tests/st_sparc...done.
[New LWP 1]
[New LWP 1]
[Thread debugging using libthread_db enabled]
[New Thread 1 (LWP 1)]
Core was generated by `./st_sparc'.
Program terminated with signal 10, Bus error.
#0 0x00010de8 in func (str=0x77d1, sz=,
key=0x77c0 "") at size_test.c:6
6 printf ("str: %lx:%lx\n", ip, *ip);
(gdb)
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: csiphash on Sparc
On 10.10.17 16:10, William Brown <wibr...@redhat.com> wrote: > > On Fri, 2017-10-06 at 10:21 +0200, Carsten Grzemba wrote: > > Currently the code src/libsds/external/csiphash/csiphash.c do not work on > > Sparc. > > The casting void* or char* to unit64_t* throws Bus-Error. > > > > The solution would be to copy the content of the void and char pointer so > > that the variabeles are suitably aligned. > > To prevent have to use malloc: do we know the max of src_sz? > > > > > What line is this? I assume you are refering to: > > https://pagure.io/389-ds-base/blob/master/f/src/libsds/external/csiphash/csiphash.c#_82 > yes! > > (https://pagure.io/389-ds-base/blob/master/f/src/libsds/external/csiphash/csiphash.c#_82) > > No, we can't know the max of src_sz, in theory it could be uint64_t max. > So this may not be an option. > So is malloc for uint64 alignment of the src variable the only option? > > > > Are you trying this on a 32bit platform perhaps? What's the arch of the > machine with the issue? > 64bit, Fujitsu M4000 $ isainfo -v 64-bit sparcv9 applications fmaf vis2 vis popc Carsten ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] csiphash on Sparc
Currently the code src/libsds/external/csiphash/csiphash.c do not work on Sparc. The casting void* or char* to unit64_t* throws Bus-Error. The solution would be to copy the content of the void and char pointer so that the variabeles are suitably aligned. To prevent have to use malloc: do we know the max of src_sz? Thanks ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: Rust-Lang
> > As a curious question, does solaris have rustlang support ? > > Not in the moment, but there some issues open for rust related Solaris. So it tried somebody already. ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: PR_ASSERT problem
On 28.09.17 00:49, William Brown <wibr...@redhat.com> wrote: > > On Wed, 2017-09-20 at 14:30 +0200, Carsten Grzemba wrote: > > my build on OpenIndiana with the IllumOS provided NSPR cores on startup of > > some commands: > > > > $ pwdhash > > Assertion failure: 0 == lock->notified.length, at > > /jenkins/jobs/oi-userland/workspace/components/library/mozilla-nspr/nspr-4.12/nspr/pr/src/pthreads/ptsynch.c:159 > > /usr/bin/pwdhash: line 60: 5993: Abort(coredump) > > > > $ pstack core > > core 'core' of 5993: /usr/bin/amd64/pwdhash-bin > > fd7fff2b4eda _lwp_kill () + a > > fd7fff2480e0 raise (6) + 20 > > fd7fff220818 abort () + 98 > > fd7ff943fda2 () > > fd7ff9457828 PR_DestroyLock () + d8 > > fd7ff978bc2a slapi_entry_free () + 11a > > 00402888 init_config () + 2d8 > > 00402d43 main () + 353 > > 0040235c _start () + 6c > > > > Before I dive in the source code, has anyone a hint where I can start to > > search what happens here? > > > > Sounds like the lock may not have been created properly? Sadly I think > you need to dive into the source, > > :( > > Let me know if you need any other advice. > It works, if I compile with AC_DEFINE([USE_POSIX_RWLOCKS], [1], [POSIX rwlocks]) Because this is also set in Linux, I guess the NSPR Threads is not tested anymore. ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] PR_ASSERT problem
my build on OpenIndiana with the IllumOS provided NSPR cores on startup of some commands: $ pwdhash Assertion failure: 0 == lock->notified.length, at /jenkins/jobs/oi-userland/workspace/components/library/mozilla-nspr/nspr-4.12/nspr/pr/src/pthreads/ptsynch.c:159 /usr/bin/pwdhash: line 60: 5993: Abort(coredump) $ pstack core core 'core' of 5993: /usr/bin/amd64/pwdhash-bin fd7fff2b4eda _lwp_kill () + a fd7fff2480e0 raise (6) + 20 fd7fff220818 abort () + 98 fd7ff943fda2 () fd7ff9457828 PR_DestroyLock () + d8 fd7ff978bc2a slapi_entry_free () + 11a 00402888 init_config () + 2d8 00402d43 main () + 353 0040235c _start () + 6c Before I dive in the source code, has anyone a hint where I can start to search what happens here? ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] JSS4 Source repository
Where can I find the current JSS source? The mozilla source is unmaintained. THX -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] winsync Changes for 716980 and 47314
Am 01.04.14 schrieb Noriko Hosoi nho...@redhat.com: Hello Carsten, Could it be possible to share your failed test cases with us for our debugging? I have setup an winsync replication agreement with a W2K8R2 AD. There is enabled the SFU for managing the Posix attributes uidnumber, gidnumber, unixshell, unixhomedir, nisdomain, ... The test failes if I change some of the Posix attributes. These changes will not synched. The reason is that for #716980 the value for rawentry is reseted before winsync cb is called and for #47314 the cb posix_winsync_pre_ds_mod_user_cb returns immediately if rawentry is NULL. Before #47314 only account enable/disable have to fail. sync_acct_disable I took from ipa. I don't know exactly what is the difference beteween ad_entry and rawentry. Perhaps all works as before if I ignore rawentry in the cb code and use ad_entry instead. Carsten Thanks, --noriko Rich Megginson wrote: On 04/01/2014 07:34 AM, Carsten Grzemba wrote: Hi Rich, this breaks the current implementaion for posix-winsync: Bug 716980 - winsync uses old AD entry if new one not found https://bugzilla.redhat.com/show_bug.cgi?id=716980 Resolves: bug 716980 Bug Description: winsync uses old AD entry if new one not found Reviewed by: nhosoi (Thanks!) Branch: master Fix Description: Clear out the old raw_entry before doing the search. This will leave a NULL in the raw entry. winsync plugins will need to handle a NULL for the raw_entry and/or ad_entry. In the moment posix_winsync_pre_ds_mod_user_cb returns imediataly on raw_entry == NULL How should the plugin handle the NULL for raw_entry? Not sure. Please reopen that ticket. If it broke posix-winsync, it is likely to break other winsync plugins (e.g. ipa winsync). Carsten -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Changes for
Hi Rich, this breaks the current implementaion for posix-winsync: Bug 716980 - winsync uses old AD entry if new one not found https://bugzilla.redhat.com/show_bug.cgi?id=716980 Resolves: bug 716980 Bug Description: winsync uses old AD entry if new one not found Reviewed by: nhosoi (Thanks!) Branch: master Fix Description: Clear out the old raw_entry before doing the search. This will leave a NULL in the raw entry. winsync plugins will need to handle a NULL for the raw_entry and/or ad_entry. In the moment posix_winsync_pre_ds_mod_user_cb returns imediataly on raw_entry == NULL How should the plugin handle the NULL for raw_entry? Carsten -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] WinSync: uniquemember not updated if user moved from one OU to an other OU
In an Winsync setup AD-DS (oneWay: fromWindows) we have the problem that the uniquemember attribute of groups will not updated if a user moved from on OU to an other. Winsync will only update the user itself and not the groups where it is memberof. This behaviour is similar like described in ticket 31 manager attribute not updated. Referential integrity plugin is enabled and setup for uniquemember, but I don't know if this work in a winsync environment. Is this a know problem? observed in version 1.2.11.15 -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
