search for: process_root

...9;m not an expert on GC but I'll take a look ... Thanks :) > > > For some strange reason I get segmentation fault in process_pointer in > > semispace.c (I've implemented a small collector, hopefully :). The fault > > occurs when I do: > > > > printf("process_root[0x%p] = 0x%p\n", (void*) Root, (void*) *Root); > > > > I.e, when I reference Root. > > I don't know what "Root" is but possibly the %p substitution with > "*Root" isn't valid. Hmm, ok, that was in the file when I checked it out from the cvs. Th...

Seems like Root in process_root sometimes is a null pointer. Wonder if it is my fault? :) *debugging* , Tobias On Wed, 18 Aug 2004, Tobias Nurmiranta wrote: > > On Wed, 18 Aug 2004, Reid Spencer wrote: > > On Wed, 2004-08-18 at 11:54, Tobias Nurmiranta wrote: > > > > Okay. I'm not an expert on GC but...

...lem might be related to some strange memory fault created by my frontend, but I'll try here to get some feedback. For some strange reason I get segmentation fault in process_pointer in semispace.c (I've implemented a small collector, hopefully :). The fault occurs when I do: printf("process_root[0x%p] = 0x%p\n", (void*) Root, (void*) *Root); I.e, when I reference Root. My frontend creates llvm assembly with llvm-gcroot in the following manner: ... %r22 = alloca uint ;; typetagged integers/pointers %r23 = cast uint* %r22 to sbyte** call void %llvm.gcroot(sbyte** %r23, sbyte* nul...

...; here to get some feedback. Okay. I'm not an expert on GC but I'll take a look ... > For some strange reason I get segmentation fault in process_pointer in > semispace.c (I've implemented a small collector, hopefully :). The fault > occurs when I do: > > printf("process_root[0x%p] = 0x%p\n", (void*) Root, (void*) *Root); > > I.e, when I reference Root. I don't know what "Root" is but possibly the %p substitution with "*Root" isn't valid. > My frontend creates llvm assembly with llvm-gcroot in the following > manner: >...

...mod (smbldap.c:392) ==28624== by 0x4AA410F: ldapsam_create_user (pdb_ldap.c:5305) ==28624== by 0x4AC046E: pdb_create_user (pdb_interface.c:542) ==28624== by 0x4AB1401: local_password_change (passdb.c:745) ==28624== by 0x10B4AB: password_change (smbpasswd.c:264) ==28624== by 0x10BC87: process_root (smbpasswd.c:466) ==28624== by 0x10C1AC: main (smbpasswd.c:627) ==28624== ==28624== Invalid read of size 1 ==28624== at 0x56B4578: ldap_mods_free (in /usr/lib/i386-linux-gnu/libldap_r-2.4.so.2.10.3) ==28624== by 0x5731A13: ldapmod_destructor (smbldap.c:266) ==28624== by 0x4A64B53: _tal...

On Fri, Mar 04, 2016 at 10:53:17AM +0100, Volker Lendecke wrote: > On Wed, Mar 02, 2016 at 09:23:34AM +0000, Rowland penny wrote: > > OK, here is the output: > > Can you try the attached (UNTESTED!) patch? > > Thanks, Gna, should have at least compiled it.... New patch :-) Volker -- SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen phone: +49-551-370000-0, fax:

...-f -o linked.bc alloc_loop.bc ~/llvm/runtime/GC/SemiSpace/Debug/semispace.bc because it seemed easier than working out if and how to get dynamic loading and linking to work. Perhaps the process will be smoother when I restart using projects/sample/ . Running linked.bc outputs Garbage collecting!! process_root[0x0xbffff3f0] = 0x0x41257008 process_root[0x0xbffff3ec] = 0x0x41257012 lli((anonymous namespace)::PrintStackTrace()+0x1a)[0x857f236] lli((anonymous namespace)::SignalHandler(int)+0xcb)[0x857f4a9] [0xffffe420] lli(llvm::ExecutionEngine::runFunctionAsMain... Which is too be expected since llvm_gc_co...

..._set_mod (smbldap.c:392) ==2405== by 0x4A9FC2B: ldapsam_create_user (pdb_ldap.c:5304) ==2405== by 0x4ABB376: pdb_create_user (pdb_interface.c:542) ==2405== by 0x4AACBF9: local_password_change (passdb.c:745) ==2405== by 0x10B29B: password_change (smbpasswd.c:264) ==2405== by 0x10BA77: process_root (smbpasswd.c:466) ==2405== by 0x10BF9C: main (smbpasswd.c:627) ==2405== ==2405== Invalid read of size 4 ==2405== at 0x56AB548: ldap_mods_free (in /usr/lib/i386-linux-gnu/libldap_r-2.4.so.2.10.3) ==2405== by 0x5728963: ldapmod_destructor (smbldap.c:266) ==2405== by 0x4A61AA3: _talloc_fr...

On 01/03/16 21:35, Garming Sam wrote: > Hi Rowland, > > This new segfault seems unrelated to the previous one. It's probably > something like a double free, which typically shouldn't be that hard to > fix. If you try running the tool under valgrind, it should provide > enough information to fix the issue. > > > Cheers, > > Garming > Who or what is

...ibc.so.6(__libc_start_main+0x108)[0x401307f8] Aborted How should we get this to run? Also the code in runtime/GC/SemiSpace/semispace.c doesn't seem to do anything other than call process_pointer for every gcroot pointer. static void process_pointer(void **Root, void *Meta) { printf("process_root[0x%p] = 0x%p\n", (void*) Root, (void*) *Root); } Are there any examples of LLVM performing active garbage collection? In the dev archives (http://mail.cs.uiuc.edu/pipermail/llvmdev/2004-July/001527.html) Chris said there are no frontends with GC support, but it might get into Java first. Wh...

...iuc.edu/pipermail/llvm-commits/Week-of-Mon-20041025/019891.html > Also the code in runtime/GC/SemiSpace/semispace.c doesn't seem to do > anything other than call process_pointer for every gcroot pointer. > > static void process_pointer(void **Root, void *Meta) { > printf("process_root[0x%p] = 0x%p\n", (void*) Root, (void*) *Root); > } Correct. The semispace collector hasn't been implemented all of the way. The code generator and runtime interfaces provide you with all of the hooks that you need to implement a garbage collector though. > Are there any examples o...

.../GC/SemiSpace/Debug/semispace.bc > because it seemed easier than working out if and how to get dynamic > loading and linking to work. Perhaps the process will be smoother when > I restart using projects/sample/. Okay, sounds good. Running linked.bc outputs > Garbage collecting!! > process_root[0x0xbffff3f0] = 0x0x41257008 > process_root[0x0xbffff3ec] = 0x0x41257012 > lli(llvm::ExecutionEngine::runFunctionAsMain... > > Which is too be expected since llvm_gc_collect in > llvm/runtime/GC/SemiSpace/semispace.c ends with abort(); > I believe we have our work cut out for us....

...sword_change (remote_mach=0x0, username=0x800081c0 <user_name> "ldap09", old_passwd=0x0, new_pw=0x800118b8 "p4ssword", local_flags=577) at ../source3/utils/smbpasswd.c:264 ret = {v = 0} err_str = 0x0 msg_str = 0x0 #7 0x80003c88 in process_root (local_flags=577) at ../source3/utils/smbpasswd.c:466 pwd = 0x1 result = 0 old_passwd = 0x0 __FUNCTION__ = "process_root" #8 0x800041ad in main (argc=3, argv=0xbffffd14) at ../source3/utils/smbpasswd.c:627 ok = true frame =...

On Fri, Mar 04, 2016 at 04:16:44PM +0000, Rowland penny wrote: > On 04/03/16 09:58, Volker Lendecke wrote: > >On Fri, Mar 04, 2016 at 10:53:17AM +0100, Volker Lendecke wrote: > >>On Wed, Mar 02, 2016 at 09:23:34AM +0000, Rowland penny wrote: > >>>OK, here is the output: > >>Can you try the attached (UNTESTED!) patch? > >> > >>Thanks, >

...ib/libc.so.1...done. Reading symbols from /usr/lib/libmp.so.2...done. #0 0x31014 in cli_error () (gdb) where #0 0x31014 in cli_error () #1 0x2bc68 in cli_errstr () #2 0x3f5fc in modify_trust_password () #3 0x3fb88 in change_trust_account_password () #4 0x241ec in join_domain () #5 0x2463c in process_root () #6 0x24d74 in main () Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org

...t () #6 0xef69bb5c in xdr_free () #7 0xef69f854 in nis_freeresult () #8 0x38a48 in add_nisp21pwd_entry () #9 0x390ec in add_nisppwd_entry () #10 0x35900 in add_smbpwd_entry () #11 0x39258 in add_new_user () #12 0x393d8 in local_password_change () #13 0x2322c in password_change () #14 0x236cc in process_root () #15 0x23b70 in main ()

Ok, I *might* be getting this from the assembly code. The assembly code has: L_llvm_gc_root_chain$non_lazy_ptr: .indirect_symbol _llvm_gc_root_chain .long 0 and I see it being used in the function preamble. Is that a ref to an extern symbol or the def? I.e., is it referring to StackEntry *llvm_gc_root_chain; that I must have in my GC C code? (semispace.c has it) SO!