Re: macOS status

"Kirill A. Korinsky" <[email protected]> Sun, 24 Dec 2023 19:34:52 +0100
Newsgroups	gmane.lisp.gcl.devel
Message-ID	<[email protected]>
I really doubt that it makes something useful.

I've attached to process by debug and it says:
> (lldb) bt
> ^C* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
>   * frame #0: 0x0000000000000000
>     frame #1: 0x00007ff803977ff1 libsystem_c.dylib`__smakebuf + 384
>     frame #2: 0x00007ff803985b52 libsystem_c.dylib`__swsetup + 148
>     frame #3: 0x00007ff803963b92 libsystem_c.dylib`__v2printf + 86
>     frame #4: 0x00007ff803975912 libsystem_c.dylib`vfprintf_l + 54
>     frame #5: 0x00007ff803991fd3 libsystem_c.dylib`printf + 174
>     frame #6: 0x000000010000dd1d raw_pre_gcl`error + 253
>     frame #7: 0x00000001000b443c raw_pre_gcl`my_malloc + 44
>     frame #8: 0x00007ff803909149 libsystem_malloc.dylib`_malloc_zone_malloc_instrumented_or_legacy + 88
>     frame #9: 0x00007ff803977ff1 libsystem_c.dylib`__smakebuf + 384
>     frame #10: 0x00007ff803985b52 libsystem_c.dylib`__swsetup + 148
>     frame #11: 0x00007ff803963b92 libsystem_c.dylib`__v2printf + 86
>     frame #12: 0x00007ff803975912 libsystem_c.dylib`vfprintf_l + 54
>     frame #13: 0x00007ff803991fd3 libsystem_c.dylib`printf + 174
>     frame #14: 0x000000010000dd1d raw_pre_gcl`error + 253
>     frame #15: 0x00000001000b443c raw_pre_gcl`my_malloc + 44
>     frame #16: 0x00007ff803909149 libsystem_malloc.dylib`_malloc_zone_malloc_instrumented_or_legacy + 88
>     frame #17: 0x00007ff803977ff1 libsystem_c.dylib`__smakebuf + 384
>     frame #18: 0x00007ff803985b52 libsystem_c.dylib`__swsetup + 148
>     frame #19: 0x00007ff803963b92 libsystem_c.dylib`__v2printf + 86
>     frame #20: 0x00007ff803975912 libsystem_c.dylib`vfprintf_l + 54
>     frame #21: 0x00007ff803991fd3 libsystem_c.dylib`printf + 174
>     frame #22: 0x000000010000dd1d raw_pre_gcl`error + 253
>     frame #23: 0x00000001000b443c raw_pre_gcl`my_malloc + 44
>     frame #24: 0x00007ff803909149 libsystem_malloc.dylib`_malloc_zone_malloc_instrumented_or_legacy + 88
> 

anyway, with some with some debuger using I was able to get the first stacktrace:

> (lldb) bt
> * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
>   * frame #0: 0x000000010000d790 raw_pre_gcl`error
>     frame #1: 0x00000001000bf89c raw_pre_gcl`my_malloc + 44
>     frame #2: 0x00007ff817d43abb libsystem_malloc.dylib`_malloc_zone_malloc + 125
>     frame #3: 0x00007ff817decc74 libsystem_c.dylib`__parsefloat_buf + 195
>     frame #4: 0x00007ff817de3cc7 libsystem_c.dylib`__svfscanf_l + 2842
>     frame #5: 0x00007ff817de3185 libsystem_c.dylib`vsscanf_l + 221
>     frame #6: 0x00007ff817de9d83 libsystem_c.dylib`sscanf + 160
>     frame #7: 0x000000010000ba04 raw_pre_gcl`update_real_maxpage + 436
>     frame #8: 0x00000001000b6fad raw_pre_gcl`gcl_init_alloc + 589
>     frame #9: 0x00000001000bf8ad raw_pre_gcl`my_malloc + 61
>     frame #10: 0x00007ff817d43abb libsystem_malloc.dylib`_malloc_zone_malloc + 125
>     frame #11: 0x00007ff817decc74 libsystem_c.dylib`__parsefloat_buf + 195
>     frame #12: 0x00007ff817de3cc7 libsystem_c.dylib`__svfscanf_l + 2842
>     frame #13: 0x00007ff817de3185 libsystem_c.dylib`vsscanf_l + 221
>     frame #14: 0x00007ff817de9d83 libsystem_c.dylib`sscanf + 160
>     frame #15: 0x000000010000ba04 raw_pre_gcl`update_real_maxpage + 436
>     frame #16: 0x00000001000b6fad raw_pre_gcl`gcl_init_alloc + 589
>     frame #17: 0x000000010000cb90 raw_pre_gcl`main + 128
>     frame #18: 0x000000010276152e dyld`start + 462

and if I build gcl with -g it allows to see the crash point:

> * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
>     frame #0: 0x000000010000dbbc raw_pre_gcl`error(s="Bad malloc") at main.c:687:24
>    684 	void
>    685 	error(char *s)
>    686 	{
> -> 687 	        if (catch_fatal>0 && interrupt_enable )
>    688 	            {catch_fatal = -1;
>    689 	#ifdef SGC
>    690 	    if (sgc_enabled)
> Target 0: (raw_pre_gcl) stopped.

but any attempt to use bt leads to 100% CPU usage by LLDB.

All of this indicates that something quite bad with memory when this ENV is enabled.

--
wbr, Kirill

> On 24. Dec 2023, at 18:25, Camm Maguire <[email protected]> wrote:
> 
> Greetings!  Might want to try figures between 0.1 and 1.0 to see where
> it breaks.  At least we know you are emulating sbrk now as in the past.
> 
> This error is in reference to mac specific code contributed by a
> knowledgeable user quite some time ago in unexmacosx.c:
> 
> void init_darwin_zone_compat () {
> 
>  extern unsigned malloc_num_zones;
>  extern malloc_zone_t **malloc_zones;
>  unsigned nmzc;
>  malloc_zone_t *mzc[10];
>  unsigned i;
> 
>  nmzc=malloc_num_zones;
>  assert(nmzc<=sizeof(mzc)/sizeof(*mzc));
>  memcpy(mzc,malloc_zones,nmzc*sizeof(*mzc));
> 
>  gcl_zone=&gcl_zone_body;
> 
>  gcl_zone->size               = (void *) stub_size;
>  gcl_zone->malloc             = (void *) stub_malloc;
>  gcl_zone->calloc             = (void *) stub_calloc;
>  gcl_zone->valloc             = (void *) stub_valloc;
>  gcl_zone->realloc            = (void *) stub_realloc;
>  gcl_zone->free               = (void *) stub_free;
>  gcl_zone->destroy            = (void *) stub_free;
>  gcl_zone->batch_malloc       = (void *) stub_malloc;
>  gcl_zone->batch_free         = (void *) stub_free;
> 
> #ifdef HAVE_MALLOC_ZONE_MEMALIGN
>  gcl_zone->free_definite_size = (void *) stub_free;
>  gcl_zone->memalign           = (void *) stub_memalign;
> #endif
> 
>  for (i=0;i<nmzc;i++)
>    malloc_zone_unregister(mzc[i]);
> 
>  /* Make our zone the default zone.  */
>  malloc_zone_register (gcl_zone);
>  for (i=0;i<nmzc;i++)
>    malloc_zone_register (mzc[i]);
> 
> }
> 
> Pretty sure you are calling this function just once unless
> CAN_UNRANDOMIZE_SBRK is defined in your config.h.  This pertains to my
> previous comments that your configure output appeared to be able to
> unrandomize sbrk even though it wasn't going to use it.  Is this defined
> in h/gclincl.h?
> 
> Take care,
> 
> "Kirill A. Korinsky" <[email protected]> writes:
> 
>> Hello,
>> 
>> On 24. Dec 2023, at 15:34, Camm Maguire <[email protected]> wrote:
>> 
>> Please export the environment variable GCL_MEM_MULTIPLE=0.1 or similar
>> to limit gcl to 1/10 of system memory.  There are also ways to do this
>> at the lisp level in terms of absolute instead of percentage figures.
>> 
>> build stuck with output:
>> 
>> ar x libpre_gcl.a $(ar t libpre_gcl.a |grep ^gcl_)
>> /Users/catap/src/gcl/gcl/unixport/raw_pre_gcl /Users/catap/src/gcl/gcl/unixport/ -libdir /Users/catap/src/gcl/gcl/ < foo
>> raw_pre_gcl(82333,0x105781600) malloc: Attempted to register zone more than once: 0x1007272c8
>> 
>> meanwhile raw_pre_gcl consumes 100% CPU core.
> 
> --
> Camm Maguire			     		    [email protected]
> ==========================================================================
> "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
signature.asc (application/pgp-signature, 833 B)