Summary: | [bisect] FTBFS on commit 9767d3b5 (glapi: Fix OpenGL ES 1.1 and 2.0 interop) | ||
---|---|---|---|
Product: | Mesa | Reporter: | Dave Witbrodt <dawitbro> |
Component: | Other | Assignee: | mesa-dev |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | medium | CC: | virtuousfox |
Version: | git | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: | Crash of makedepend with options shown |
Description
Dave Witbrodt
2011-01-22 19:18:34 UTC
makedepend crashed when being executed in src/mapi/shared-glapi/. If your xutils-dev is not up-to-date, update it first. If it does not help, could you run makedepend manually and maybe change some of its options to see if the crash can be avoided? You can see how mesa executes makedepend by removing the last "@" sign in src/mapi/shared-glapi/Makefile. (In reply to comment #1) > makedepend crashed when being executed in src/mapi/shared-glapi/. OK > If your xutils-dev is not up-to-date, update it first. Thanks for mentioning this. I use Debian "unstable" which has the latest packages available; I update frequently. As it turns out, libc6 and xutils-dev had just been updated. My first assumption was that the bug was in one of those updates and not in the Mesa sources. After downgrading to the previous version of xutils-dev (7.5+5) and two previous Debian releases of libc6 (all versions were 2.11.2, but the Debian maintainers often add patches and release new builds) I found that in all combinations of xutils-dev + libc6 that I tried the crashing of makedepend only appeared with commit 9767d3b5... (and after), but all prior commits that I tried during the bisect process worked fine. This information was known to me when I posted the bug report, but I failed to mention it because I wrongly assumed it was irrelevant. The current version of xutils-dev in Debian unstable is 7.6+1. > If it does not help, could you run makedepend manually and maybe change some > of its options to see if the crash can be avoided? You can see how mesa > executes makedepend by removing the last "@" sign in > src/mapi/shared-glapi/Makefile. I haven't experimented with changing the options for makedepend yet. I have removed the "@" and captured the resulting output. Here is the relevant part: running /usr/bin/makedepend /usr/bin/makedepend -fdepend -I/usr/lib/gcc/x86_64-linux-gnu/4.4.5/include -I/usr/lib/gcc/x86_64-linux-gnu/4.4.5/include-fixed -f- -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XCB_DRI2 -DHAVE_LIBUDEV -I../../../include -I../../../src/mapi -DMAPI_MODE_GLAPI -DMAPI_ABI_HEADER=\"shared-glapi/glapi_mapi_tmp.h\" \ ../../../src/mapi/mapi/entry.c ../../../src/mapi/mapi/mapi_glapi.c ../../../src/mapi/mapi/stub.c ../../../src/mapi/mapi/table.c ../../../src/mapi/mapi/u_current.c ../../../src/mapi/mapi/u_execmem.c ../../../src/mapi/mapi/u_thread.c 2>/dev/null | sed -e 's,^../../../src/mapi/mapi/,,' \ > depend *** glibc detected *** /usr/bin/makedepend: double free or corruption (!prev): 0x000000000172a480 *** It seems like makedepend should fail more gracefully in any case, so I should file a bug report against it. The options passed to 'configure' in my build system are shown in my build output; have you succeeded in building Mesa at (or after) commit 9767d3b5... using those options? Is there something wrong with that combination of options? (My current build setup has been working for nearly a month, so I'm assuming it's OK to use.) If I have any success altering the options to makedepend, I will let you know. I will attach the entire output of the build I quoted above immediately following this message. Created attachment 42428 [details]
Crash of makedepend with options shown
hm, something similar happened with me on Gentoo while building 32bit mesa from git on 64bit system. config: ./configure --prefix=/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib32 --enable-32-bit --disable-64-bit --with-x --disable-debug --disable-selinux --disable-static --enable-glx-tls --enable-xcb --disable-glw --disable-motif --disable-asm --enable-egl --enable-glu --disable-glut --enable-opengl --enable-openvg --enable-shared-glapi --enable-gles1 --enable-gles2 --with-dri-drivers= --enable-gallium --enable-gallium-egl --enable-gallium-swrast --with-state-trackers=,glx,egl,dri,vega --enable-gallium-llvm --disable-gallium-noop --disable-gallium-svga --disable-gallium-nouveau --disable-gallium-i915 --disable-gallium-i965 --disable-gallium-radeon --enable-gallium-r600 --with-egl-platforms=,x11,drm,fbdev --disable-gallium-llvm piece of log: python2 -t -O -O ../../../../src/mapi/mapi/mapi_abi.py \ --printer shared-glapi --mode lib ../gen/gl_and_es_API.xml > ../../../../src/mapi/shared-glapi/glapi_mapi_tmp.h gmake[3]: Leaving directory `/var/tmp/portage/media-libs/mesa-9999-r3/work/32/Mesa-9999/src/mapi/glapi/gen-es' running /usr/bin/makedepend *** glibc detected *** /usr/bin/makedepend: free(): invalid next size (fast): 0x0000000001c66430 *** ======= Backtrace: ========= /lib/libc.so.6(+0x795c2)[0x2b74113235c2] /lib/libc.so.6(cfree+0x73)[0x2b74113273f3] /usr/bin/makedepend[0x403a10] /usr/bin/makedepend[0x403f6e] /usr/bin/makedepend[0x403a10] /usr/bin/makedepend[0x403c1f] /usr/bin/makedepend[0x403f6e] /usr/bin/makedepend[0x403a10] /usr/bin/makedepend[0x402604] /lib/libc.so.6(__libc_start_main+0xfd)[0x2b74112c8cdd] /usr/bin/makedepend[0x400fc9] ======= Memory map: ======== 00400000-00407000 r-xp 00000000 08:03 1049927 /usr/bin/makedepend 00606000-00607000 r--p 00006000 08:03 1049927 /usr/bin/makedepend 00607000-00608000 rw-p 00007000 08:03 1049927 /usr/bin/makedepend 00608000-0061c000 rw-p 00000000 00:00 0 01bc0000-01d67000 rw-p 00000000 00:00 0 [heap] 2b7410e76000-2b7410e96000 r-xp 00000000 08:03 153382 /lib64/ld-2.12.2.so 2b7410e96000-2b7410f06000 rw-p 00000000 00:00 0 2b7411095000-2b7411096000 r--p 0001f000 08:03 153382 /lib64/ld-2.12.2.so 2b7411096000-2b7411097000 rw-p 00020000 08:03 153382 /lib64/ld-2.12.2.so 2b7411097000-2b7411098000 rw-p 00000000 00:00 0 2b7411098000-2b74110a7000 r-xp 00000000 08:03 1259011 /usr/lib64/libsandbox.so 2b74110a7000-2b74112a6000 ---p 0000f000 08:03 1259011 /usr/lib64/libsandbox.so 2b74112a6000-2b74112a7000 r--p 0000e000 08:03 1259011 /usr/lib64/libsandbox.so 2b74112a7000-2b74112a8000 rw-p 0000f000 08:03 1259011 /usr/lib64/libsandbox.so 2b74112a8000-2b74112aa000 rw-p 00000000 00:00 0 2b74112aa000-2b7411424000 r-xp 00000000 08:03 153383 /lib64/libc-2.12.2.so 2b7411424000-2b7411624000 ---p 0017a000 08:03 153383 /lib64/libc-2.12.2.so 2b7411624000-2b7411628000 r--p 0017a000 08:03 153383 /lib64/libc-2.12.2.so 2b7411628000-2b7411629000 rw-p 0017e000 08:03 153383 /lib64/libc-2.12.2.so 2b7411629000-2b7411630000 rw-p 00000000 00:00 0 2b7411630000-2b7411632000 r-xp 00000000 08:03 153366 /lib64/libdl-2.12.2.so 2b7411632000-2b7411832000 ---p 00002000 08:03 153366 /lib64/libdl-2.12.2.so 2b7411832000-2b7411833000 r--p 00002000 08:03 153366 /lib64/libdl-2.12.2.so 2b7411833000-2b7411834000 rw-p 00003000 08:03 153366 /lib64/libdl-2.12.2.so 2b7411834000-2b7411836000 rw-p 00000000 00:00 0 2b7411878000-2b741188d000 r-xp 00000000 08:03 140819 /lib64/libgcc_s.so.1 2b741188d000-2b7411a8c000 ---p 00015000 08:03 140819 /lib64/libgcc_s.so.1 2b7411a8c000-2b7411a8d000 r--p 00014000 08:03 140819 /lib64/libgcc_s.so.1 2b7411a8d000-2b7411a8e000 rw-p 00015000 08:03 140819 /lib64/libgcc_s.so.1 2b7414000000-2b7414021000 rw-p 00000000 00:00 0 2b7414021000-2b7418000000 ---p 00000000 00:00 0 7fff08f63000-7fff08f88000 rw-p 00000000 00:00 0 [stack] 7fff08fe9000-7fff08fea000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] but it was non-fatal and compilation just carried on. since it's non-fatal who knows how long it were happening. glibc is 2.12.2, makedepend is 1.0.3. (In reply to comment #1) Some further information. The 'depend' file generated by 'makedepend' ends up with this as its contents: $ cat src/mapi/shared-glapi/depend # DO NOT DELETE entry.o: ../../../src/mapi/mapi/entry.h entry.o: ../../../src/mapi/mapi/u_compiler.h entry.o: ../../../src/mapi/mapi/u_current.h entry.o: ../../../src/mapi/glapi/glapi.h entry.o: ../../../src/mapi/glapi/glthread.h entry.o: ../../../src/mapi/mapi/u_thread.h entry.o: /usr/include/pthread.h entry.o: /usr/include/features.h entry.o: /usr/include/bits/predefs.h entry.o: /usr/include/sys/cdefs.h entry.o: /usr/include/bits/wordsize.h entry.o: /usr/include/gnu/stubs.h entry.o: /usr/include/gnu/stubs-64.h entry.o: /usr/include/endian.h entry.o: /usr/include/bits/endian.h entry.o: /usr/include/bits/byteswap.h entry.o: /usr/include/sched.h entry.o: /usr/include/bits/types.h entry.o: /usr/include/bits/typesizes.h entry.o: /usr/lib/gcc/x86_64-linux-gnu/4.4.5/include/stddef.h entry.o: /usr/include/time.h /usr/include/bits/sched.h entry.o: /usr/include/signal.h entry.o: /usr/include/bits/sigset.h entry.o: /usr/include/bits/pthreadtypes.h entry.o: /usr/include/bits/setjmp.h entry.o: ../../../src/mapi/mapi/u_macros.h entry.o: /usr/include/stdlib.h entry.o: /usr/include/bits/waitflags.h entry.o: /usr/include/bits/waitstatus.h entry.o: /usr/include/xlocale.h /usr/inc) entry.o: /usr/include/sys/select.h entry.o: /usr/include/bits/select.h entry.o: /usr/include/bits/time.h entry.o: /usr/include/sys/sysmacros.h entry.o: /usr/include/alloca.h entry.o: ../../../src/mapi/mapi/mapi_tmp.h entry.o: ../../../src/mapi/shared-glapi/glapi_mapi_tmp.h entry.o: ../../../include/GL/gl.h entry.o: ../../../include/GL/glext.h entry.o: /usr/include/inttypes.h /usr/include/stdint.h entry.o: /usr/include/bits/wchar.h The 11th line before the last line looks bad: entry.o: /usr/include/xlocale.h /usr/inc) There is also no newline at the end of the file, but all the 'depend' files generated by the last working version of Mesa seem to have one. I doubt this is relevant: it is obviously a result of the crash, not the cause. But I thought I would mention it in case it is a clue to a developer here. I found that executing this works: $ /usr/bin/makedepend -I/usr/lib/gcc/x86_64-linux-gnu/4.4.5/include -I/usr/lib/gcc/x86_64-linux-gnu/4.4.5/include-fixed -f- -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XCB_DRI2 -DHAVE_LIBUDEV -I../../../include -I../../../src/mapi -DMAPI_MODE_GLAPI -DMAPI_ABI_HEADER="shared-glapi/glapi_mapi_tmp.h" ../../../src/mapi/mapi/entry.c ../../../src/mapi/mapi/mapi_glapi.c ../../../src/mapi/mapi/stub.c ../../../src/mapi/mapi/table.c ../../../src/mapi/mapi/u_current.c ../../../src/mapi/mapi/u_execmem.c ../../../src/mapi/mapi/u_thread.c 2>/dev/null | sed -e 's,^../../../src/mapi/mapi/,,' > depend The Makefile seems to be executing this (see Comment 2 above): $ /usr/bin/makedepend -I/usr/lib/gcc/x86_64-linux-gnu/4.4.5/include -I/usr/lib/gcc/x86_64-linux-gnu/4.4.5/include-fixed -f- -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XCB_DRI2 -DHAVE_LIBUDEV -I../../../include -I../../../src/mapi -DMAPI_MODE_GLAPI -DMAPI_ABI_HEADER=\"shared-glapi/glapi_mapi_tmp.h\" ../../../src/mapi/mapi/entry.c ../../../src/mapi/mapi/mapi_glapi.c ../../../src/mapi/mapi/stub.c ../../../src/mapi/mapi/table.c ../../../src/mapi/mapi/u_current.c ../../../src/mapi/mapi/u_execmem.c ../../../src/mapi/mapi/u_thread.c 2>/dev/null | sed -e 's,^../../../src/mapi/mapi/,,' > depend The difference is the escaped quotation marks around the define value for MAPI_ABI_HEADER. Thanks, that is helpful. Commit b825e4955243b8ecb57e58afafd8b2286fdd4369 should hopefully fix this. Can you try again? fixes things for me. thanks! (In reply to comment #7) > Thanks, that is helpful. Commit b825e4955243b8ecb57e58afafd8b2286fdd4369 > should hopefully fix this. Can you try again? The build succeeds now. Thanks! Now I need to do surgery on my homemade 'debian' directory to get the packages building again, but that should not take long. As a non-developer, may I ask a couple of questions: 1. Are you losing necessary dependency info by simply filtering out the indirect header file specified by MAPI_ABI_HEADER? 2. Has Mesa been building correctly for you between 9767d3b... and b825e49...? I presume so, and I wonder whether you build with way different configure options or whether you have some different build tools (or versions of build tools). Thanks, Dave W. (In reply to comment #9) > (In reply to comment #7) > > Thanks, that is helpful. Commit b825e4955243b8ecb57e58afafd8b2286fdd4369 > > should hopefully fix this. Can you try again? > > The build succeeds now. Thanks! > > Now I need to do surgery on my homemade 'debian' directory to get the packages > building again, but that should not take long. > > As a non-developer, may I ask a couple of questions: > > 1. Are you losing necessary dependency info by simply filtering out the > indirect header file specified by MAPI_ABI_HEADER? The dependency is described manually in the Makefile. > 2. Has Mesa been building correctly for you between 9767d3b... and b825e49...? > I presume so, and I wonder whether you build with way different configure > options or whether you have some different build tools (or versions of build > tools). I built normally. I think makedepend was also crashing for me, but the error was silently redirected to /dev/null and I luckily had a syntactically correct "depend" file. > > Thanks, > Dave W. (In reply to comment #10) > (In reply to comment #9) > > 1. Are you losing necessary dependency info by simply filtering out the > > indirect header file specified by MAPI_ABI_HEADER? > > The dependency is described manually in the Makefile. Yes, I see that now after looking more carefully at the changes in the new patch. > > 2. Has Mesa been building correctly for you between 9767d3b... and > > b825e49...? > > I built normally. I think makedepend was also crashing for me, but the error > was silently redirected to /dev/null and I luckily had a syntactically correct > "depend" file. Interesting. Not "luckily," though, since it prevented you from catching the problem before you applied the commit that caused makedepend to barf. In the end, I'm glad I could help you to find the problem. DW |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.