Re: Heads up: libffi 3.4 rebuild in rawhide today

[Vít Ondruch <vondruch@xxxxxxxxxx>]

I have reported this here:

https://bugzilla.redhat.com/show_bug.cgi?id=2040380

And I'd appreciate any help to figure out what is going on.


Vít


Dne 12. 01. 22 v 19:33 Vít Ondruch napsal(a):
> So as I already mentioned, the following fails:
>
>
> ~~~
>
> $ ./miniruby -I./lib -I. -I.ext/common ./tool/runruby.rb 
> --extout=.ext  -- --disable-gems "./test/runner.rb" --ruby="./miniruby 
> -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext  -- 
> --disable-gems" --excludes-dir=./test/excludes --name='!/memory_leak/' 
> test/fiddle/test_import.rb test/ruby/test_autoload.rb -v -n 
> '/TestAutoload#test_autoload_fork/'
>
> ~~~
>
>
> While the command on itself is not really comprehensible, the main 
> executable is the runruby.rb file, which essentially sets some 
> environment followed by `exec` [1]. I believe it execs something 
> similar to the following command:
>
>
> ~~~
>
> $ LD_LIBRARY_PATH=. ./ruby -I./lib -I. -I./tool/lib -I.ext/common 
> --disable-gems -rtest/fiddle/test_import.rb 
> -rtest/ruby/test_autoload.rb -e ''  -- -v -n 
> '/TestAutoload#test_autoload_fork/'
>
> ~~~
>
>
> But the command above succeeds. So it must be some strange interaction 
> due to `exec` call?
>
>
> Vít
>
>
> [1] https://github.com/ruby/ruby/blob/v3_1_0/tool/runruby.rb#L181
>
>
> Dne 12. 01. 22 v 18:36 Vít Ondruch napsal(a):
> > I wish I had answers for you.
> >
> > Nevertheless, I'd help if I knew how to debug the detached children 
> > after fork, because they are failing earlier then the main process. I 
> > was using `set follow-fork-mode child` but that does nothing :/
> >
> > I think that exec or fork is the culprit, in some way.
> >
> >
> > Vít
> >
> >
> > Dne 11. 01. 22 v 22:41 Carlos O'Donell napsal(a):
> > > On 1/11/22 13:45, Vít Ondruch wrote:
> > > > Thread 1 "ruby" received signal SIGABRT, Aborted.
> > > > 0x00007ffff78a764c in __pthread_kill_implementation () from 
> > > > /lib64/libc.so.6
> > > > Missing separate debuginfos, use: dnf debuginfo-install 
> > > > glibc-2.34.9000-36.fc36.x86_64 gmp-6.2.1-1.fc36.x86_64 
> > > > libxcrypt-4.4.27-1.fc36.x86_64 zlib-1.2.11-30.fc35.x86_64
> > > > (gdb) bt
> > > > #0  0x00007ffff78a764c in __pthread_kill_implementation () from 
> > > > /lib64/libc.so.6
> > > > #1  0x00007ffff785a656 in raise () from /lib64/libc.so.6
> > > > #2  0x00007ffff7844833 in abort () from /lib64/libc.so.6
> > > > #3  0x00007ffff4d0a5b8 in dlfree (mem=0x7ffff7bf1010) at 
> > > > ../src/dlmalloc.c:4350
> > > This is libffi's internal allocator detecting an inconsistency.
> > >
> > > > #4  0x00007ffff4d190b1 in dealloc (ptr=0x5555558c1c00) at 
> > > > /builddir/build/BUILD/ruby-3.1.0/ext/fiddle/closure.c:32
> > > This is fiddle calling ffi_closure_free() because 
> > > USE_FFI_CLOSURE_ALLOC is non-zero.
> > >
> > > The original closure was allocated in allocate() in fiddle.
> > >
> > > What happened to the closure between allocation and free?
> > >
> > > Does the memory location change?
> > >
> > > Does something corrupt the closure?
> > >
> > > > #5  0x00007ffff7cb7801 in run_final (zombie=140737300557440, 
> > > > objspace=0x55555555d800) at /builddir/build/BUILD/ruby-3.1.0/gc.c:4011
> > > > #6  finalize_list (objspace=objspace@entry=0x55555555d800, 
> > > > zombie=140737300557440) at /builddir/build/BUILD/ruby-3.1.0/gc.c:4030
> > > > #7  0x00007ffff7cb80cc in rb_objspace_call_finalizer 
> > > > (objspace=0x55555555d800) at 
> > > > /builddir/build/BUILD/ruby-3.1.0/gc.c:4194
> > > > #8  0x00007ffff7ca56eb in rb_ec_finalize (ec=0x55555555dd70) at 
> > > > /builddir/build/BUILD/ruby-3.1.0/eval.c:164
> > > > #9  rb_ec_cleanup (ec=ec@entry=0x55555555dd70, ex0=<optimized out>) 
> > > > at /builddir/build/BUILD/ruby-3.1.0/eval.c:256
> > > > #10 0x00007ffff7ca5c14 in ruby_run_node (n=0x7ffff7699660) at 
> > > > /builddir/build/BUILD/ruby-3.1.0/eval.c:321
> > > > #11 0x000055555555518f in main (argc=<optimized out>, 
> > > > argv=<optimized out>) at ./main.c:47
> > > > (gdb) f 3
> > > > #3  0x00007ffff4d0a5b8 in dlfree (mem=0x7ffff7bf1010) at 
> > > > ../src/dlmalloc.c:4350
> > > > 4350          USAGE_ERROR_ACTION(fm, p);
> > > We only get here when the incoming pointer is invalid.
> > >
> > > > (gdb) l
> > > > 4345              check_free_chunk(fm, p);
> > > > 4346              goto postaction;
> > > > 4347            }
> > > > 4348          }
> > > > 4349        erroraction:
> > > > 4350          USAGE_ERROR_ACTION(fm, p);
> > > > 4351        postaction:
> > > > 4352          POSTACTION(fm);
> > > > 4353        }
> > > > 4354      }

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure