a
оба 2
Size: a a a
2021 June 21
M
ls /var/db/pkg/sys-libs |grep glibc
ΔΒ
# ldd --version
ldd (Gentoo 2.33 p3) 2.33
ΔΒ
в убунте где не падает — 2.31
ΔΒ
(gdb) bt
#0 __tzfile_compute (timer=86400, use_localtime=1, leap_correct=0xffffb0b0, leap_hit=0xffffb0b4, tp=0xffffb59c) at tzfile.c:657
#1 0xf7d91a17 in __tz_convert (timer=86400, use_localtime=1, tp=0xffffb59c) at tzset.c:580
#2 0xf7d8f5c7 in __GI___localtime64_r (tp=0xffffb59c, t=<synthetic pointer>) at localtime.c:30
#3 __localtime_r (t=0xffffb5cc, tp=0xffffb59c) at localtime.c:41
#4 0x0809c517 in ?? ()
#5 0x0809c9b9 in ?? ()
#6 0x0809cb84 in ?? ()
#7 0x0804fc36 in ?? ()
#8 0x0805006a in ?? ()
#9 0x08050a69 in ?? ()
#10 0x08051461 in ?? ()
#11 0xf7cf4875 in __libc_start_main (main=0x80513e0, argc=4, argv=0xffffd1b4, init=0x8190ae0, fini=0x8190ad0, rtld_fini=0xf7fdb820 <_dl_fini>, stack_end=0xffffd1ac)
at ../csu/libc-start.c:332
#12 0x0804dce1 in ?? ()
вот так лучше?
ΔΒ
точно не поможет
бинарь проприетарная и еще вдобавок немного хаканная )
бинарь проприетарная и еще вдобавок немного хаканная )
m
так может ему таки дать tzfile там где он хочет?
ΔΒ
я если честно охреневаю. в дизасме сегв вот тут:
в сорце tzfile.c тоже ничего аццкого нет в той строке
0xf7d92af9 <+153>: psrlq $0x20,%xmm1
0xf7d92afe <+158>: movd %xmm1,%eax
0xf7d92b02 <+162>: sbb %eax,%edx
0xf7d92b04 <+164>: jge 0xf7d93065 <__tzfile_compute+1541>
=> 0xf7d92b0a <+170>: psubq 0x10(%esp),%xmm0
0xf7d92b10 <+176>: mov 0x24(%esp),%eax
0xf7d92b14 <+180>: push $0x0
0xf7d92b16 <+182>: push $0xf0c2ac
0xf7d92b1b <+187>: lea -0x1(%eax),%esi
в сорце tzfile.c тоже ничего аццкого нет в той строке
ΔΒ
хотя...
невыровненный доступ?
(gdb) info registers
esp 0xffffb02c 0xffffb02c
невыровненный доступ?
m
на первый взгляд они вообще не поменялись
m
второго не будет, я глаза мою
ΔΒ
да, но компилятор поменялся зато
ΔΒ
в смысле в убунте 20.04 и в генте разные
m
ну поздравляю, таки выглядит как баг в компиляторе. возможно и в глибси при этом тоже
ΔΒ
(gdb) bt
#0 0xf7d8fa91 in __tzfile_read (file=0xf7e69ec8 "/etc/localtime", extra=0, extrap=0x0) at tzfile.c:156
#1 0xf7d8f363 in tzset_internal (always=always@entry=1) at tzset.c:405
#2 0xf7d8f4c0 in __tzset () at tzset.c:551
#3 0xf7d8de3a in __GI___mktime64 (tp=0xffff1ba8) at mktime.c:529
#4 __GI_mktime (tp=0xffff1c60) at mktime.c:549
#5 0x0807f38d in ?? ()
#6 0x08084eba in ?? ()
#7 0x08085fea in ?? ()
#8 0x08096365 in ?? ()
#9 0x0809fb7c in ?? ()
#10 0x080a1035 in ?? ()
#11 0x080a2333 in ?? ()
#12 0x0804f80f in ?? ()
#13 0x0804fcb6 in ?? ()
#14 0x0805006a in ?? ()
#15 0x08050a69 in ?? ()
#16 0x08051461 in ?? ()
#17 0xf7cf186d in __libc_start_main (main=0x80513e0, argc=4, argv=0xffffd194, init=0x8190ae0, fini=0x8190ad0, rtld_fini=0xf7fdc0d0 <_dl_fini>, stack_end=0xffffd18c)
at ../csu/libc-start.c:332
#18 0x0804dce1 in ?? ()
пересобрал глибц 9ым гцц (который я благополучно не стал удалять когда приехал 10ый)
баг остался но в другом месте теперь :)
ΔΒ
=> 0xf7d8fa91 <+833>: movaps (%esp),%xmm1
...
esp 0xffff1a48 0xffff1a48
тоже типа невыровненный аксес в память
ΔΒ
movAps — aligned
m
да почини ты ему /etc/localtime как он хочет
ΔΒ
может вот изза этого:
суть была в том, чтоб собирать glibc без новомодных sse3 avx etc команд
но возможно такой -march плохо влияет на 32битную сборку
# cat glibc.env
...
FEATURES="${FEATURES} splitdebug nostrip"
CFLAGS="${CFLAGS} -march=x86-64 -ggdb"
суть была в том, чтоб собирать glibc без новомодных sse3 avx etc команд
но возможно такой -march плохо влияет на 32битную сборку