[Pkg-pascal-devel] Bug#826300: Share knowledge on fpc and powerpc issue

[Gianfranco Costamagna]

Hi,

>Good finding, but I miss the words "on powerpc" ;) .

true, obviously only powerpc (partch.debian.org) was tested :)

>That file is not extremely big and the change is not incredibly large.>We should be able to nail this down for the FTBFS. Still, the issue may
>be outside this file as multiple functions moved from this file to
>fpmkunit.pp (without much change).
>
>I tried to read through the code, and the weird thing is that all the
>processing seems to be already done. The config file seems to be
>complete at the place where it segfaults. And all the writing code
>hasn't changed AFAICT. Reading the code is hinting at the idea of
>Alexander that it is an issue in _IO_wsetb in glibc on powerpc. However,
>the solution of reverting really hints in the other direction. I don't
>have the feeling I came closer to the solution.

the problem seems to be in some external functions, not called anymore
with the "previous" code version.
Something external to that file is writing bad data on the struct used in that
_IO_wsetb function

and the glib implementation seems really similar between 2.22 and 2.23
http://sources.debian.net/src/glibc/2.23-2/libio/wgenops.c/?hl=103#L103
http://sources.debian.net/src/glibc/2.22-13/libio/wgenops.c/?hl=107#L107

I'm out of ideas, it took two days to do the necessary rebuilds and testing,
and a lot more to trim the changes into the above "patch", even if I know
the issue is not fixed, but somewhat hidden again.
Unfortunately I can't debug it more, I would really like to debug the functions
inside glibc


--- update after some sleep ---

I think now I got the right clue :)


libio/wgenops.c
libio/genops.c

^^ here the glibc files interested in this debugging, and at the end a possible solution
Program received signal SIGSEGV, Segmentation fault.
__GI__IO_wsetb (f=f at entry=0xff50ca0 <_IO_stdout_>, b=b at entry=0x0, eb=eb at entry=0x0, a=a at entry=0) at wgenops.c:105
105	in wgenops.c
(gdb) bt
#0  __GI__IO_wsetb (f=f at entry=0xff50ca0 <_IO_stdout_>, b=b at entry=0x0, eb=eb at entry=0x0, a=a at entry=0) at wgenops.c:105
#1  0x0fe36644 in _IO_unbuffer_all () at genops.c:918
#2  _IO_cleanup () at genops.c:960
#3  0x0fded188 in __run_exit_handlers (status=0, listp=<optimized out>, run_list_atexit=run_list_atexit at entry=true) at exit.c:95
#4  0x0fded25c in __GI_exit (status=<optimized out>) at exit.c:104
#5  0x0fdd18b8 in generic_start_main (main=0x100003e4, argc=1, argv=0xfffef694, auxvec=0xfffef6f8, init=<optimized out>, rtld_fini=<optimized out>, stack_end=<optimized out>, fini=<optimized out>)
at ../csu/libc-start.c:325
#6  0x0fdd1abc in __libc_start_main (argc=<optimized out>, argv=<optimized out>, ev=<optimized out>, auxvec=<optimized out>, rtld_fini=<optimized out>, stinfo=<optimized out>, stack_on_entry=<optimized out>)
at ../sysdeps/unix/sysv/linux/powerpc/libc-start.c:116
#7  0x00000000 in ?? ()
(gdb) p f 
$9 = (_IO_FILE *) 0xff50ca0 <_IO_stdout_>
(gdb) p f->_mode
$10 = 1124073472
(gdb) p f->_wide_data->_IO_buf_base
Cannot access memory at address 0x6c69627b
(gdb) p f->_freeres_buf
$11 = (void *) 0xffffffff
(gdb) quit


obviously _IO_buf_base seems to be the reason for the failure, since it can't be accessed.

I found this by looking at the above bug reports:
https://bugs.launchpad.net/ubuntu/+source/libisoburn/+bug/1571684
https://bugzilla.redhat.com/show_bug.cgi?id=1283284
https://bugzilla.redhat.com/show_bug.cgi?id=1264556

this leads to the conclusion that this might be caused by a multiprocess concurrent call
when exit is invoked every atexit is run, but some process in the meanwhile exited, cleaning
the struct used by wsetb

I'm not providing a solution, but the patch "revert" shows that a new process were spawn in the previous
release, so maybe just by chance that process was preventing the struct from being free'd on exit
or something similar.

Does this hint sounds better? :)

I really would like to put debugging code into glibc, but it seems mostly impossible without some real hardware.

but the redhat bugs seems to point into some interesting and promising direction to me

G.