| Summary: | app-text/texlive-core-2010-r1 pdftex: segfault against app-crypt/heimdal-1.4.1_pre20110301 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Martin von Gagern <Martin.vGagern> |
| Component: | Current packages | Assignee: | Gentoo Kerberos Maintainers <kerberos> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | aballier, tex |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://github.com/heimdal/heimdal/pull/7 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | Make prim static | ||
Created attachment 264593 [details, diff]
Make prim static
This patch makes the symbol prim static and therefore local to its translation unit. It won't get exported, hence it won't cause trouble for pdftex.
By the way, it would be nice if the heimdal ebuild would at some point, directly or indirectly, call epatch_user, so that users with an interest in development could simply drop their patches into /etc/portage/patches/app-crypt/heimdal in order to test them. I guess defering to base_src_prepare would be the canonical way of doing so.
If you include this patch, don't forget to revbump, as it's a runtime thing. Perhaps you should also warn users to run "revdep-rebuild -L libasn1.so", as this patch obviously changes the ABI without a soname change. Although I'd expect any app that used that symbol would have done so in error, just like pdftex.
Created a github pull request: https://github.com/heimdal/heimdal/pull/7 Also sent a mail to heimdal-bugs@..., haven't found an archive for it yet. It seems another approach to this problem here would be adding -fno-common to the CFLAGS for texlive-core. Looking at the docs, I wonder whether I'd like to enable tht compiler flag by default on my system... http://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-fno_002dcommon-2168 (In reply to comment #0) > Is there some way to tell the toolchain that some symbols should not be > resolved from shared libs, but only from static objects passed on the command > line? Not that I know of. > Or do we need to prevent heimdal from exporting these symbols? They are part of the public interface and I am not going to start localizing unless upstream does as well. > Currently the ASN library from heimdal exports everything: Unfortunately yes. Perhaps one can use symbol versioning in the calling program, something like __asm__(".symver prim,prim@SOME_TAG"); Should be better than runtime segfault. Also, I am not familiar with texlive/pdftex but why does it link against heimdal? Doesn't seem right. (In reply to comment #3) > It seems another approach to this problem here would be adding -fno-common to > the CFLAGS for texlive-core. Confirmed: compiling heimdal without the patch, and texlive-core with -fno-common does resolve the issue as well. (In reply to comment #4) > > Or do we need to prevent heimdal from exporting these symbols? > > They are part of the public interface and I am not going to start localizing > unless upstream does as well. Only by accident, I'd say. There is no other reference to that symbol prim except for that single file, which is the reason why my patch works. In particular, it's not included in any public headers, so no other application could ever access it in a reasonably sane way. Is this the reason why the kerberos herd isn't even cc-ed to this report here? > Perhaps one can use symbol versioning in the calling program, something like > __asm__(".symver prim,prim@SOME_TAG"); I thought symver was for exported symbols... but never mind. If you were going to tweak the sources, the proper tweak would probably be annotating the prim declaration in pdftexextra.c with __attribute__((nocommon)). Unfortunately pdftexextra.c seems to be build-time generated as well. Therefore adjusting CFLAGS seems the more feasible approach. > Also, I am not familiar with texlive/pdftex but why does it link against > heimdal? Doesn't seem right. Let's see if I can trace this... pdftex depends on libpoppler depends on libcurl depends on libgssapi depends on libkrb5 depends on libasn1. So keypoints in my configuration are app-text/poppler[curl] and net-misc/curl[kerberos] and obviously app-crypt/heimdal. (In reply to comment #5) > Is this the reason why the kerberos herd isn't even cc-ed to this report here? Ignore that, somehow missed the "Assigned To" field. Sorry. Heimdal upstream maintainer Love Hornquist Astrand merged my patch: https://github.com/heimdal/heimdal/commit/642b748a885c741c5f33590168c15a9b9fc0 Thanks for the report and pushing it upstream. +*heimdal-1.4.1_pre20110304 (04 Mar 2011) + + 04 Mar 2011; Eray Aslan <eras@gentoo.org> + -heimdal-1.4.1_pre20110216-r1.ebuild, -heimdal-1.4.1_pre20110301.ebuild, + +heimdal-1.4.1_pre20110304.ebuild: + Version bump for #357235. Remove old + |
Simply executing pdftex with no arguments will result in a segmentation fault. #0 ___fprintf_chk (fp=0x0, flag=1, format=0x49c8d7 "%s%s") at fprintf_chk.c:32 #1 0x000000000041299f in fprintf () at /usr/include/bits/stdio2.h:98 #2 mainbody () at pdftexini.c:5295 #3 0x000000000046410e in main (ac=<value optimized out>, av=<value optimized out>) at pdftexextra.c:788 As you can see, the FILE* value passed to fprintf is NULL. Looking at pdftexini.c (which is only generated during build, so unpack isn't enough) I found the call passed stdout. Adding a watchpoint for that I found: Old value = (struct _IO_FILE *) 0x7ffff774b7a0 New value = (struct _IO_FILE *) 0x0 0x00000000004051ae in initialize () at pdftexini.c:206 206 prim [k ]= prim [0 ]; (gdb) p &stdout $13 = (struct _IO_FILE **) 0x6b1c10 (gdb) p &prim $14 = (twohalves (*)[2101]) 0x6b1880 (gdb) p &prim[2101] $15 = (twohalves *) 0x6b5a28 Seems gdb is of the opinion that stdout really is somewhere within the prim array. Here is what objdump -T thinks of these two: 00000000006b1880 g DO .bss 0000000000000390 HEIMDAL_ASN1_1.0 prim 00000000006b1c10 g DO .bss 0000000000000008 GLIBC_2.2.5 stdout These are the same addresses printed above, but the prim thing heimdal refers to alsmost certainly isn't the one pdftex meant. I guess heimdal entered the scene at link time as some kind of transitive dependency from poppler. What have things looked like before link time? texlive-20100722-source/texk/web2c/pdftex-pdftexextra.o: 00000000000041a8 O *COM* 0000000000000020 prim texlive-20100722-source/texk/web2c/pdftex-pdftex0.o: 0000000000000000 *UND* 0000000000000000 prim Is there some way to tell the toolchain that some symbols should not be resolved from shared libs, but only from static objects passed on the command line? Or do we need to prevent heimdal from exporting these symbols? Currently the ASN library from heimdal exports everything: https://github.com/heimdal/heimdal/blob/master/lib/asn1/version-script.map I guess I'll contact heimdal upstream about this.