我制作了一个C ++工具，用于3D模型的离屏渲染。 渲染是使用OSMesa库完成的。
该软件在一年多的时间里完美运行，我停下来对它进行更新，就像6个月前一样。 与此同时，我的开发环境已多次更新。
现在我再次编译它，发现了一个意外的错误。
该软件的普通版本仍然按预期工作，但静态链接的版本是segfaulting。
我假设错误在OSmesa配置/编译/链接过程中是我的，而不是在库代码中，但是有关更好地调试分段错误的任何建议都值得赞赏。
尝试了很多编译过程的变化而没有成功，我现在很困惑。 任何人都可以看到我在下面描述的一些步骤中做的蠢事？
我使用在我的系统（12.0.6）中工作的相同版本的共享库重新编译了OSmesa库的静态版本，禁用了所有不需要的功能（使用基于Ubuntu的系统，没有静态版本的OSmesa lib是可从存储库获得）：
./configure \ --disable-xvmc \ --disable-glx \ --disable-dri \ --with-dri-drivers="" \ --with-gallium-drivers="" \ --disable-shared-glapi \ --disable-egl \ --with-egl-platforms="" \ --enable-osmesa \ --enable-gallium-llvm=no \ --disable-gles1 \ --disable-gles2 \ --enable-static \ --disable-shared这是我的屏幕外渲染工具的编译命令：
g++ -std=c++11 -Wall -O3 -g -static -static-libgcc -static-libstdc++ ./src/measure_model.cpp model.o thumbnail.o -o measure_model_debug -pthread -lOSMesa -ldl -lm -lpng -lz -lcrypto这是一个警告，我通过使用OSMesa进行静态编译，并且它甚至在一年前使用工作静态二进制文件存在：
/home/XXX/XXX/backend/lambda/mesa/mesa-12.0.6/src/mesa/main/dlopen.h:52: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking这是我从运行该工具获得的：
Segmentation fault (core dumped)但是，如果我只是跳过OSmesa上下文创建步骤（显然所有的3D渲染），就不会产生分段错误
这是回溯：
#0 0x0000000000000000 in ?? () #1 0x00000000004af20a in mtx_init (type=4, mtx=0xe10f70) at ../../include/c11/threads_posix.h:215 #2 _mesa_NewHashTable () at main/hash.c:135 #3 0x000000000052f295 in _mesa_alloc_shared_state (ctx=ctx@entry=0xdcc9b0) at main/shared.c:67 #4 0x000000000046e717 in _mesa_initialize_context (ctx=ctx@entry=0xdcc9b0, api=api@entry=API_OPENGL_COMPAT, visual=, share_list=share_list@entry=0x0, driverFunctions=driverFunctions@entry=0x7fffffffcd40) at main/context.c:1192 #5 0x000000000046c870 in OSMesaCreateContextAttribs (attribList=attribList@entry=0x7fffffffd290, sharelist=) at osmesa.c:834 #6 0x000000000046ccdc in OSMesaCreateContextExt (format=, depthBits=, stencilBits=, accumBits=, sharelist=) at osmesa.c:660 #7 0x0000000000468742 in generate_thumbnail(Model*, Json::Value) () #8 0x0000000000401c7d in main (argc=, argv=) at ./src/measure_model.cpp:107静态链接二进制是一个严格的要求。
分段错误发生在我用来编译工具的同一台机器上（OSmesa静态库也在同一台机器上编译），但在同一工具的非静态链接版本中没有分段错误。
I made a C++ tool for off-screen rendering of 3D models. The rendering is done using OSMesa library.
The software was working flawlessly for more than a year, and I stopped to make updates to it something like 6 months ago. In the meanwhile my development environment was updated multiple times.
Now I was compiling it again and found an unexpected bug.
The plain version of the software was still working as expected, but the statically linked one is segfaulting.
I'm assuming that the error is mine in the OSmesa configuration/compilation/linking procedure and not in the library code, but any advice about better debugging of the segmentation fault is appreciated.
Having tried numerous variations of the compilation process without success, I'm now quite stuck. Anyone can see something stupid I'm doing in some of the steps described below?
I recompiled a static version of the OSmesa library with the same version of the shared library that is working in my system (12.0.6), disabling all the non-needed features (using an Ubuntu based system, no static version of OSmesa lib is available from repositories):
./configure \ --disable-xvmc \ --disable-glx \ --disable-dri \ --with-dri-drivers="" \ --with-gallium-drivers="" \ --disable-shared-glapi \ --disable-egl \ --with-egl-platforms="" \ --enable-osmesa \ --enable-gallium-llvm=no \ --disable-gles1 \ --disable-gles2 \ --enable-static \ --disable-sharedThis is the compile command of my off-screen rendering tool:
g++ -std=c++11 -Wall -O3 -g -static -static-libgcc -static-libstdc++ ./src/measure_model.cpp model.o thumbnail.o -o measure_model_debug -pthread -lOSMesa -ldl -lm -lpng -lz -lcryptoThis is a warning that I was getting by statically compiling using OSMesa, and it was present even a year ago with the working static binary:
/home/XXX/XXX/backend/lambda/mesa/mesa-12.0.6/src/mesa/main/dlopen.h:52: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linkingThis is what I get from running the tool:
Segmentation fault (core dumped)But no segmentation fault is produced if I simply skip the OSmesa context creation step (and obviously all the 3D rendering)
This is the backtrace:
#0 0x0000000000000000 in ?? () #1 0x00000000004af20a in mtx_init (type=4, mtx=0xe10f70) at ../../include/c11/threads_posix.h:215 #2 _mesa_NewHashTable () at main/hash.c:135 #3 0x000000000052f295 in _mesa_alloc_shared_state (ctx=ctx@entry=0xdcc9b0) at main/shared.c:67 #4 0x000000000046e717 in _mesa_initialize_context (ctx=ctx@entry=0xdcc9b0, api=api@entry=API_OPENGL_COMPAT, visual=, share_list=share_list@entry=0x0, driverFunctions=driverFunctions@entry=0x7fffffffcd40) at main/context.c:1192 #5 0x000000000046c870 in OSMesaCreateContextAttribs (attribList=attribList@entry=0x7fffffffd290, sharelist=) at osmesa.c:834 #6 0x000000000046ccdc in OSMesaCreateContextExt (format=, depthBits=, stencilBits=, accumBits=, sharelist=) at osmesa.c:660 #7 0x0000000000468742 in generate_thumbnail(Model*, Json::Value) () #8 0x0000000000401c7d in main (argc=, argv=) at ./src/measure_model.cpp:107A statically linked binary is a strict requirement.
The segmentation fault is happening on the same machine I use to compile the tool (OSmesa static lib is compiled in the same machine too), but no segmentation fault in the non-statically linked version of the same tool.
更多推荐
发布评论