Re: [Mesa-dev] Minecraft crash in nouveau_dri.so
Ilia, thank you for looking at it.
On 04/30/2014 12:47 PM, Ilia Mirkin wrote:
The relevant code:
if (slab-free == 0) {
LIST_DEL(slab-head);
LIST_ADD(slab-head, bucket-full);
}
And the LIST_ADD is line 206 (on the 9.2 branch).
Do you know if multiple GL threads are used?
I do not know, is there a good way to tell?
According to top java at least is using more than 100% CPU, but I think
there's a client server model even in single player.
I ran Minecraft on another computer with more RAM (12GiB) and a newer
graphics card (GeForce 9800 GTX+) that also uses the nouveau driver and
it worked fine.
I decreased the Render Distance in Minecraft and everything seemed
fine on the first computer (4GiB RAM).
The trouble might only occur in a low memory condition.
signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] build: Add --enable-gallium-osmesa flag.
On 08/21/2013 10:06 AM, Brian Paul wrote: On 08/20/2013 03:18 PM, Matt Turner wrote: The Gallium implementation is apparently not ready for regular consumption, so as much as I hate adding more build-time options, here's another. The intention was for the old/swrast version of OSMesa would wind up in lib/ while the gallium version would wind up in lib/gallium/. I thought that's what I implemented. Or is it make install that's causing overwriting? After make install : my install directory has no lib/gallium my install directory has /lib/libOSMesa.so.8.0.0 which is the gallium version and symlinks to it. my build directory has lib/libOSMesa.so and lib/libOSMesa.so.8 which are symlinks to libOSMesa.so.8.0.0 which does not exist. my build directory has lib/gallium my build directory has libOSMesa.so.8.0.0 and symlinks to it in lib/gallium signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] segfault in pstip_bind_sampler_states
On 08/12/2013 10:29 AM, Brian Paul wrote:
On 08/09/2013 01:50 PM, Kevin H. Hobbs wrote:
(gdb) print pstip
$1 = (struct pstip_stage *) 0xff66331aff66331a
I don't think my actual RAM goes that high.
That looks suspect since the low and high halves of the address are the
same.
I believe pstip-state gets it's funky value in null_sw_create () at
null_sw_winsys.c:146
My heavily edited gdb session follows :
$ gdb /home/kevin/kitware/VTK_OSMesa_Build/bin/vtkpython
(gdb) run lots of options
Program received signal SIGSEGV, Segmentation fault.
pstip_bind_sampler_states (pipe=optimized out, num=0, sampler=0x0) at
draw/draw_pipe_pstipple.c:713
713 pstip-state.samplers[i] = NULL;
(gdb) bt
#0 pstip_bind_sampler_states (pipe=optimized out, num=0, sampler=0x0)
at draw/draw_pipe_pstipple.c:713
#1 0x7fffdf75839c in cso_release_all (ctx=ctx@entry=0x15eebe0) at
cso_cache/cso_context.c:307
(gdb) break cso_context.c:307
(gdb) run lots of options
(gdb) step
pstip_bind_sampler_states (pipe=0x13d4960, num=0, sampler=0x0) at
draw/draw_pipe_pstipple.c:706
706 {
(gdb) next
711memcpy(pstip-state.samplers, sampler, num * sizeof(void *));
# oops not a debug build
(gdb) print pstip
$1 = (struct pstip_stage *) 0x1360d30
(gdb) print pstip-state
$2 = {samplers = {0x7fffdf863b80 null_sw_displaytarget_unmap,...
(gdb) print (pstip-state)
$3 = (struct {...} *) 0x1360db0
(gdb) print (pstip-state.samplers)
$4 = (void *(*)[16]) 0x1360db0 # duh
(gdb) watch *0x1360db0
Hardware watchpoint 2: *0x1360db0
(gdb) run lots of options
Hardware watchpoint 2: *0x1360db0
Old value = unreadable
New value = 3369
vtkCellLinks::InsertCellReference (this=0x1359ce0, ptId=252, pos=4,
cellId=3369)
at /home/kevin/kitware/VTK/Common/DataModel/vtkCellLinks.h:159
159 }
(gdb) continue
Continuing.
Hardware watchpoint 2: *0x1360db0
Old value = 3369
New value = 0
__libc_calloc (n=optimized out, elem_size=optimized out) at
malloc.c:3286
3286if (nclears 8) {
(gdb) bt
#0 __libc_calloc (n=optimized out, elem_size=optimized out) at
malloc.c:3286
#1 0x7fffdf863c23 in null_sw_create () at null_sw_winsys.c:135
#2 0x7fffdf595656 in osmesa_create_screen () at target.c:43
#3 0x7fffdf887b93 in get_st_manager () at osmesa.c:151
#4 0x7fffdf888263 in OSMesaCreateContextExt (format=6408,
depthBits=24,
stencilBits=optimized out, accumBits=0, sharelist=optimized out)
at osmesa.c:557
#5 0x7fffdcc02a10 in vtkOSOpenGLRenderWindow::CreateOffScreenWindow
(this=0xebc270, width=150,
height=150) at
/home/kevin/kitware/VTK/Rendering/OpenGL/vtkOSOpenGLRenderWindow.cxx:188 ...
(gdb) continue
Continuing.
Hardware watchpoint 2: *0x1360db0
Old value = 0
New value = -544851072
null_sw_create () at null_sw_winsys.c:146
146winsys-displaytarget_display = null_sw_displaytarget_display;
(gdb) bt
#0 null_sw_create () at null_sw_winsys.c:146
#1 0x7fffdf595656 in osmesa_create_screen () at target.c:43
#2 0x7fffdf887b93 in get_st_manager () at osmesa.c:151
#3 0x7fffdf888263 in OSMesaCreateContextExt (format=6408,
depthBits=24,
stencilBits=optimized out, accumBits=0, sharelist=optimized out)
at osmesa.c:557
#4 0x7fffdcc02a10 in vtkOSOpenGLRenderWindow::CreateOffScreenWindow
(this=0xebc270, width=150,
height=150) at
/home/kevin/kitware/VTK/Rendering/OpenGL/vtkOSOpenGLRenderWindow.cxx:188
(gdb) continue
Breakpoint 1, cso_release_all (ctx=ctx@entry=0x15eebe0) at
cso_cache/cso_context.c:307
307 ctx-pipe-bind_fragment_sampler_states( ctx-pipe, 0, NULL );
(gdb) continue
Continuing.
Program received signal SIGSEGV, Segmentation fault.
pstip_bind_sampler_states (pipe=optimized out, num=0, sampler=0x0) at
draw/draw_pipe_pstipple.c:713
713 pstip-state.samplers[i] = NULL;
signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] segfault in pstip_bind_sampler_states
On 08/13/2013 09:50 AM, Brian Paul wrote:
On 08/12/2013 11:30 AM, Kevin H. Hobbs wrote:
--30166-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) -
exiting
Well, that's not too helpful.
I think it may have been helpful.
Before Valgrind crashed it mentions that
osmesa_st_framebuffer_flush_front wrote to an address it should not have.
In the test VTK uses a filter that tiles the rendering of a (not very)
large image.
The render window is initially 150x150 and then after some fooling
around magnification is set to 3.
I think this results in what I see in gdb :
res-width0 = 450
res-height0= 450
osbuffer-width = 150
bytes = 1800
dst_stride = -600
If I read that last right then in the for loop we write 1800 bytes to
dst move back 600 bytes and write another 1800 bytes.
Are we overwriting 2/3 of what we just wrote?
Can you send me an executable?
Not quickly.
Or, is it
simple to build the test case?
I loose track of what's simple and not for me there's a cron job that
just runs a bunch of scripts while I sleep.
The test is a python wrapped test so the whole hour long build of vtk is
hard to avoid.
They are attached for good measure but all I do is:
The mesa I use is built nightly with :
./autogen.sh \
--prefix=/home/kevin/mesa_nightly \
--enable-glx \
--enable-dri \
--enable-shared-glapi \
--enable-gallium-llvm \
--with-gallium-drivers=nouveau,swrast \
--enable-osmesa
I have VTK cloned :
git clone http://vtk.org/VTK.git
I happen to be on the nightly-master branch for the dashboard but that
shouldn't matter.
ctest builds and tests VTK with :
ctest -S vtk_osmesa.cmake
Since you only want one test a build just like mine is :
VTK_BUILD=~/VTK_Build
VTK_SRC=~/VTK
mkdir $VTK_BUILD
cd $VTK_BUILD
cmake \
\
-DBUILD_EXAMPLES:BOOL=ON\
-DBUILD_SHARED_LIBS:BOOL=ON\
\
-DVTK_BUILD_ALL_MODULES:BOOL=OFF\
-DVTK_Group_Imaging:BOOL=ON\
-DVTK_Group_MPI:BOOL=ON\
-DVTK_Group_Rendering:BOOL=ON\
-DVTK_Group_StandAlone:BOOL=ON\
-DVTK_Group_Views:BOOL=ON\
\
-DVTK_WRAP_JAVA:BOOL=OFF\
-DVTK_WRAP_PYTHON:BOOL=ON\
-DVTK_WRAP_TCL:BOOL=ON\
\
-DOPENGL_INCLUDE_DIR:PATH=/home/kevin/mesa_nightly/include\
-DOPENGL_gl_LIBRARY:FILEPATH=/home/kevin/mesa_nightly/lib/libGL.so\
-DOPENGL_glu_LIBRARY:FILEPATH=/home/kevin/mesa_nightly/lib/libGLU.so\
-DVTK_OPENGL_HAS_OSMESA:BOOL=ON\
-DOSMESA_INCLUDE_DIR:PATH=/home/kevin/mesa_nightly/include\
-DOSMESA_LIBRARY:FILEPATH=/home/kevin/mesa_nightly/lib/libOSMesa.so\
\
-DVTK_USE_OFFSCREEN:BOOL=ON\
-DVTK_USE_X:BOOL=OFF\
-DVTK_USE_TK:BOOL=OFF\
$VTK_SRC
and the test is :
$VTK_BUILD/bin/vtkpython --enable-bt
$VTK_BUILD/Utilities/vtkTclTest2Py/rtImageTest.py
$VTK_SRC/Filters/Hybrid/Testing/Python/largeImageOffset.py -D
$VTK_BUILD/ExternalData/Testing -T $VTK_BUILD/Testing/Temporary
-V
$VTK_BUILD/ExternalData/Filters/Hybrid/Testing/Data/Baseline/largeImageOffset.png
-A $VTK_BUILD/Utilities/vtkTclTest2Py
ctest usually downloads the the validation image largeImageOffset.png
and the input file mentioned in the test iflamigm.3ds
I don't know if this happens without ctest.
# Client maintainer: hob...@ohio.edu
set(CTEST_SITE bubbles.hooperlab)
set(CTEST_BUILD_NAME Fedora-18_OSMesaDevel-x86_64)
set(CTEST_CONFIGURATION_TYPE Release)
set(CTEST_CMAKE_GENERATOR Unix Makefiles)
set( dashboard_model Nightly )
set( CTEST_BUILD_FLAGS -ij8 )
set( CTEST_TEST_ARGS PARALLEL_LEVEL 8 )
set( CTEST_DASHBOARD_ROOT ${CTEST_SCRIPT_DIRECTORY} )
set( CTEST_SOURCE_DIRECTORY ${CTEST_DASHBOARD_ROOT}/VTK )
set( CTEST_BINARY_DIRECTORY ${CTEST_DASHBOARD_ROOT}/VTK_OSMesa_Build )
set( VTK_USE_LARGE_DATA ON )
set( dashboard_cache
BUILD_EXAMPLES:BOOL=ON
BUILD_SHARED_LIBS:BOOL=ON
VTK_BUILD_ALL_MODULES:BOOL=OFF
VTK_Group_Imaging:BOOL=ON
VTK_Group_MPI:BOOL=ON
VTK_Group_Rendering:BOOL=ON
VTK_Group_StandAlone:BOOL=ON
VTK_Group_Views:BOOL=ON
VTK_WRAP_JAVA:BOOL=OFF
VTK_WRAP_PYTHON:BOOL=ON
VTK_WRAP_TCL:BOOL=ON
OPENGL_INCLUDE_DIR:PATH=/home/kevin/mesa_nightly/include
OPENGL_gl_LIBRARY:FILEPATH=/home/kevin/mesa_nightly/lib/libGL.so
OPENGL_glu_LIBRARY:FILEPATH=/home/kevin/mesa_nightly/lib/libGLU.so
VTK_OPENGL_HAS_OSMESA:BOOL=ON
OSMESA_INCLUDE_DIR:PATH=/home/kevin/mesa_nightly/include
OSMESA_LIBRARY:FILEPATH=/home/kevin/mesa_nightly/lib/libOSMesa.so
VTK_USE_OFFSCREEN:BOOL=ON
VTK_USE_X:BOOL=OFF
VTK_USE_TK:BOOL=OFF
)
include(${CTEST_SCRIPT_DIRECTORY}/VTKScripts/vtk_common.cmake)
update_kitware.sh
Description: application/shellscript
update_mesa.sh
Description: application/shellscript
signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] segfault in pstip_bind_sampler_states
On 08/13/2013 11:45 AM, Kevin H. Hobbs wrote: On 08/13/2013 09:50 AM, Brian Paul wrote: On 08/12/2013 11:30 AM, Kevin H. Hobbs wrote: --30166-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting Well, that's not too helpful. Ha! I can move the segfault all the way back to : Program received signal SIGSEGV, Segmentation fault. 0x7fffe0ba6d43 in osmesa_st_framebuffer_flush_front (stctx=0x1518ee0, stfbi=0x1520560, statt=ST_ATTACHMENT_FRONT_LEFT) at osmesa.c:305 305u_box_2d(0, 0, res-width0, res-height0, box); if I make the magnification on the vtkRenderLargeImage instance high enough. signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] segfault in pstip_bind_sampler_states
On 08/13/2013 01:41 PM, Kevin H. Hobbs wrote: Ha! I can move the segfault all the way back to : Program received signal SIGSEGV, Segmentation fault. 0x7fffe0ba6d43 in osmesa_st_framebuffer_flush_front (stctx=0x1518ee0, stfbi=0x1520560, statt=ST_ATTACHMENT_FRONT_LEFT) at osmesa.c:305 305u_box_2d(0, 0, res-width0, res-height0, box); if I make the magnification on the vtkRenderLargeImage instance high enough. This post was all wet ignore it. signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] segfault in pstip_bind_sampler_states
On 08/12/2013 10:29 AM, Brian Paul wrote: Can you run with valgrind? That should give us some useful info if there's a use-after-free. Sure, $ valgrind /home/kevin/kitware/VTK_OSMesa_Build/bin/vtkpython --enable-bt /home/kevin/kitware/VTK_OSMesa_Build/Utilities/vtkTclTest2Py/rtImageTest.py /home/kevin/kitware/VTK/Filters/Hybrid/Testing/Python/largeImageOffset.py -D /home/kevin/kitware/VTK_OSMesa_Build/ExternalData/Testing -T /home/kevin/kitware/VTK_OSMesa_Build/Testing/Temporary -V /home/kevin/kitware/VTK_OSMesa_Build/ExternalData/Filters/Hybrid/Testing/Data/Baseline/largeImageOffset.png -A /home/kevin/kitware/VTK_OSMesa_Build/Utilities/vtkTclTest2Py /tmp/osmesa_valgrind.txt 21 ==30166== Memcheck, a memory error detector ==30166== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==30166== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==30166== Command: /home/kevin/kitware/VTK_OSMesa_Build/bin/vtkpython --enable-bt /home/kevin/kitware/VTK_OSMesa_Build/Utilities/vtkTclTest2Py/rtImageTest.py /home/kevin/kitware/VTK/Filters/Hybrid/Testing/Python/largeImageOffset.py -D /home/kevin/kitware/VTK_OSMesa_Build/ExternalData/Testing -T /home/kevin/kitware/VTK_OSMesa_Build/Testing/Temporary -V /home/kevin/kitware/VTK_OSMesa_Build/ExternalData/Filters/Hybrid/Testing/Data/Baseline/largeImageOffset.png -A /home/kevin/kitware/VTK_OSMesa_Build/Utilities/vtkTclTest2Py ==30166== vtk version 6.1.0 DartMeasurement name=ImageError type=numeric/double0/DartMeasurementDartMeasurement name=BaselineImage type=text/stringStandard/DartMeasurementDartMeasurement name=WallTime type=numeric/double29.2597/DartMeasurement DartMeasurement name=CPUTime type=numeric/double29.19/DartMeasurement ==30166== Invalid write of size 8 ==30166==at 0x4C2C29B: memcpy@@GLIBC_2.14 (mc_replace_strmem.c:882) ==30166==by 0x1DB7DF37: osmesa_st_framebuffer_flush_front (osmesa.c:329) ==30166==by 0x1D957491: st_manager_flush_frontbuffer (st_manager.c:770) ==30166==by 0x1D92C802: display_front_buffer (st_cb_flush.c:73) ==30166==by 0x1D92C9C9: st_glFlush (st_cb_flush.c:124) ==30166==by 0x1D7CD172: _mesa_flush (context.c:1643) ==30166==by 0x1D7CCD4B: _mesa_make_current (context.c:1455) ==30166==by 0x1D95733B: st_api_make_current (st_manager.c:722) ==30166==by 0x1DB7E5F8: OSMesaMakeCurrent (osmesa.c:653) ==30166==by 0x2131C322: vtkOSOpenGLRenderWindow::MakeCurrent() (vtkOSOpenGLRenderWindow.cxx:344) ==30166==by 0x2131BC50: vtkOSOpenGLRenderWindow::DestroyWindow() (vtkOSOpenGLRenderWindow.cxx:147) ==30166==by 0x2131C128: vtkOSOpenGLRenderWindow::Finalize() (vtkOSOpenGLRenderWindow.cxx:281) ==30166== Address 0x91fdd18 is not stack'd, malloc'd or (recently) free'd ==30166== --30166-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting --30166-- si_code=80; Faulting address: 0x0; sp: 0x4030fdd50 valgrind: the 'impossible' happened: Killed by fatal signal ==30166==at 0x3806236E: mkFreeBlock (m_mallocfree.c:290) ==30166==by 0x38064436: vgPlain_arena_free (m_mallocfree.c:1846) ==30166==by 0x38029725: create_MC_Chunk (mc_malloc_wrappers.c:165) ==30166==by 0x38029944: vgMemCheck_new_block (mc_malloc_wrappers.c:283) ==30166==by 0x38029B9D: vgMemCheck___builtin_new (mc_malloc_wrappers.c:311) ==30166==by 0x3809E490: vgPlain_scheduler (scheduler.c:1667) ==30166==by 0x380AD6F9: run_a_thread_NORETURN (syswrap-linux.c:103) sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==30166==at 0x4C2A361: operator new(unsigned long) (vg_replace_malloc.c:298) ==30166==by 0x1DE5891F: llvm::JIT::removeModule(llvm::Module*) (in /home/kevin/mesa_nightly/lib/libOSMesa.so.8.0.0) ==30166==by 0x1DEA8149: LLVMRemoveModule (in /home/kevin/mesa_nightly/lib/libOSMesa.so.8.0.0) ==30166==by 0x1DB2297F: free_gallivm_state (lp_bld_init.c:200) ==30166==by 0x1DB22D08: gallivm_destroy (lp_bld_init.c:554) ==30166==by 0x1DB4A006: draw_llvm_destroy_variant (draw_llvm.c:1998) ==30166==by 0x1DB4B6E0: vs_llvm_delete (draw_vs_llvm.c:73) ==30166==by 0x1DA251DD: draw_delete_vertex_shader (draw_vs.c:142) ==30166==by 0x1DBAC1CD: llvmpipe_delete_vs_state (lp_state_vs.c:105) ==30166==by 0x1D9FAB73: cso_delete_vertex_shader (cso_context.c:608) ==30166==by 0x1D95BE3E: delete_vp_variant (st_program.c:66) ==30166==by 0x1D95BEDA: st_release_vp_variants (st_program.c:90) ==30166==by 0x1D934F9F: st_delete_program (st_cb_program.c:131) ==30166==by 0x1D9ED388: _mesa_reference_program_ (program.c:421) ==30166==by 0x1D9D8AF7: _mesa_reference_program (program.h:102) ==30166==by 0x1D9D8D22: clear_cache (prog_cache.c:126) ==30166==by 0x1D9D8E14: _mesa_delete_program_cache (prog_cache.c:159) ==30166==by 0x1D9ECC90: _mesa_free_program_data (program.c:119) ==30166==by 0x1D7CC11C: _mesa_free_context_data (context.c:1166) ==30166==by 0x1D93C691: st_destroy_context (st_context.c:310)
Re: [Mesa-dev] segfault in pstip_bind_sampler_states
On 08/09/2013 09:16 AM, Brian Paul wrote: On 08/07/2013 12:17 PM, Kevin H. Hobbs wrote: #0 pstip_bind_sampler_states (pipe=optimized out, num=0, sampler=0x0) at draw/draw_pipe_pstipple.c:713 Hmm, I'd expect memcpy() of length zero to be fine even if src/dst were null. memcpy is fine, the segfault happens at line 713 two lines below where : pstip-state.samplers[i] = NULL; I asked gdb what to print pstip-state.samplers[0] and it told me something like unavailable. Can you try this patch? I can and I will. signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] segfault in pstip_bind_sampler_states
On 08/09/2013 01:59 PM, Brian Paul wrote:
That's probably not it, given the above. Can you try setting a
breakpoint on pstip_destroy() and see if that's getting called before
the segfault? If so, things are getting freed in the wrong order.
No, it is not called before the segfault.
We do seem to enter pstip_bind_sampler_states many times before the
segfault. I do not remember this from before I had CFLAGS=-g -O0...
The last time through :
(gdb) print pstip
$1 = (struct pstip_stage *) 0xff66331aff66331a
I don't think my actual RAM goes that high.
(gdb) print pstip-state
Cannot access memory at address 0xff66331aff66339a
I should think not...
(gdb) print pipe
$2 = (struct pipe_context *) 0x13d6ec0
What does pstip_stage_from_pipe do?
(gdb) print pipe-draw
$3 = (void *) 0x137a090
(gdb) print ((struct draw_context *)(pipe-draw))-pipeline
$6 = {first = 0xffda006dffdc006e, validate = 0xffd40069ffd9006c,
flatshade = 0xffe6007affe7007d, clip =
0xffe10070ffe30072, cull = 0xffdf006fffe00070, twoside =
0xffdd006effde006f, offset =
0xffda006dffdc006d, unfilled = 0xffd8006bffd9006c, stipple =
0xffd5006affd6006b, aapoint =
0xffd00067ffd30069, aaline = 0xff66331aff66331a, pstipple =
0xff66331aff66331a, wide_line =
0xff66331aff66331a, wide_point = 0xff66331aff66331a, rasterize =
0xff66331aff66331a,
wide_point_threshold = -3.05987774e+38, wide_line_threshold =
-3.05987774e+38,
wide_point_sprites = 26 '\032', line_stipple = 51 '3', point_sprite =
102 'f', verts =
0xff66331aff66331a Address 0xff66331aff66331a out of bounds,
vertex_stride = 4284887834,
vertex_count = 4284887834}
Which looks like a whole lot of uninitialized..
signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] segfault in pstip_bind_sampler_states
One of the VTK tests (vtkFiltersHybridPython-largeImageOffset) makes OSMesa segfault. This is the top of the gdb backtrace : #0 pstip_bind_sampler_states (pipe=optimized out, num=0, sampler=0x0) at draw/draw_pipe_pstipple.c:713 #1 0x7fffdf7580fc in cso_release_all (ctx=ctx@entry=0x15f1540) at cso_cache/cso_context.c:307 #2 0x7fffdf6aebad in st_destroy_context (st=0x15da330) at ../../src/mesa/state_tracker/st_context.c:287 #3 0x7fffdf888022 in OSMesaDestroyContext (osmesa=0x13622d0) at osmesa.c:583 #4 0x7fffdcc02c13 in vtkOSOpenGLRenderWindow::DestroyOffScreenWindow (this=0xec6770) at /home/kevin/kitware/VTK/Rendering/OpenGL/vtkOSOpenGLRenderWindow.cxx:226 Do I interpret that as pstip_bind_sampler_states was sent a null pointer sampler? signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] OSMesa Driver Changed With OS Update
On 07/17/2013 06:12 PM, Brian Paul wrote: On 07/17/2013 03:10 PM, Kevin H. Hobbs wrote: Can anybody give me a clue as to what's going on? My guess is your Fedora 18 system is missing some dependency that was previously found on your Fedora 17 system. I'd try to compare Mesa config.log files from 17 vs. 18 to see what might be different. Or, just the output from running ./configure on each. The only differences that stand out to me are: F17 used llvm-3.0 and F18 uses llvm-3.3. the LLVM_LIBS variables differed. I don't have the make output from F17 but the F18 output has : gmake[3]: Entering directory `/home/kevin/mesa/src/gallium/targets/osmesa' CC target.lo GEN libOSMesa.la /usr/bin/ld: cannot find -lLLVMMCJIT /usr/bin/ld: cannot find -lLLVMBitWriter /usr/bin/ld: cannot find -lLLVMX86Disassembler /usr/bin/ld: cannot find -lLLVMX86AsmParser /usr/bin/ld: cannot find -lLLVMX86CodeGen /usr/bin/ld: cannot find -lLLVMSelectionDAG /usr/bin/ld: cannot find -lLLVMAsmPrinter /usr/bin/ld: cannot find -lLLVMMCParser /usr/bin/ld: cannot find -lLLVMX86Desc /usr/bin/ld: cannot find -lLLVMX86Info /usr/bin/ld: cannot find -lLLVMX86AsmPrinter /usr/bin/ld: cannot find -lLLVMX86Utils /usr/bin/ld: cannot find -lLLVMJIT /usr/bin/ld: cannot find -lLLVMRuntimeDyld /usr/bin/ld: cannot find -lLLVMExecutionEngine /usr/bin/ld: cannot find -lLLVMCodeGen /usr/bin/ld: cannot find -lLLVMObjCARCOpts /usr/bin/ld: cannot find -lLLVMScalarOpts /usr/bin/ld: cannot find -lLLVMInstCombine /usr/bin/ld: cannot find -lLLVMTransformUtils /usr/bin/ld: cannot find -lLLVMipa /usr/bin/ld: cannot find -lLLVMAnalysis /usr/bin/ld: cannot find -lLLVMTarget /usr/bin/ld: cannot find -lLLVMMC /usr/bin/ld: cannot find -lLLVMObject /usr/bin/ld: cannot find -lLLVMCore /usr/bin/ld: cannot find -lLLVMSupport collect2: error: ld returned 1 exit status gmake[3]: [libOSMesa.la] Error 1 (ignored) /usr/bin/mkdir -p ../../../../lib; /usr/bin/mkdir -p ../../../../lib/gallium; ln -f .libs/libOSMesa.so ../../../../lib/gallium/libOSMesa.so; ln: accessing ‘.libs/libOSMesa.so’: No such file or directory gmake[3]: [all-local] Error 1 (ignored) ln -f .libs/libOSMesa.so.8 ../../../../lib/gallium/libOSMesa.so.8; ln: accessing ‘.libs/libOSMesa.so.8’: No such file or directory gmake[3]: [all-local] Error 1 (ignored) cp .libs/libOSMesa.so.8.0.0 ../../../../lib/gallium/ cp: cannot stat ‘.libs/libOSMesa.so.8.0.0’: No such file or directory gmake[3]: [all-local] Error 1 (ignored) gmake[3]: Leaving directory `/home/kevin/mesa/src/gallium/targets/osmesa' I should have noticed this earlier but libOSMesa.so* exist in the install directory so I didn't think to check until now. In fact this output repeats for nouveau and others. In the mesa build tree for F17 lib/gallium/ has lots of stuff but is empty in the mesa build tree for F18. I cannot find these libs anywhere on my system. Everything builds if I add --with-llvm-shared-libs. There also exists the F18 package llvm-static.x86_64 which I don't have installed... When I install the static libraries everything builds. signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] OSMesa Driver Changed With OS Update
I build Mesa with OSMesa from git source for testing VTK on two hosts with: ./autogen.sh \ --prefix=/home/kevin/mesa_nightly \ --enable-glx \ --enable-dri \ --enable-shared-glapi \ --enable-gallium-llvm \ --with-gallium-drivers=nouveau,swrast \ --enable-osmesa When I used Fedora 17 OSMesa used : GL_RENDERER: Gallium 0.4 on llvmpipe (LLVM 3.0, 128 bits) I updated the OS on each host to Fedora 18 on different days. After the update each host reverted to using the old OSMesa driver: GL_RENDERER: Mesa OffScreen I used to be able to change the driver by setting GALLIUM_DRIVER and I can't do that anymore. Can anybody give me a clue as to what's going on? signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] OSMesa Driver Changed With OS Update
On 07/17/2013 06:12 PM, Brian Paul wrote: On 07/17/2013 03:10 PM, Kevin H. Hobbs wrote: Can anybody give me a clue as to what's going on? I'd try to compare Mesa config.log files from 17 vs. 18 to see what might be different. Or, just the output from running ./configure on each. Thank you for your _very_ rapid reply! I don't have any F17 boxes left but I pulled /home/kevin/mesa/config.log from the backup server with only a work day to spare before it got recycled. I'll analyze the difference in the morning. Thank you! signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Remaining VTK OSMesa Regressions 1
vtkRenderingOpenGLCxx-TestTransformCoordinateUseDouble looks like an llvmpipe issue: OSMesa-9.1.1 offscreen pass OSMesa-git softpipe pass OSMesa-git llvmpipe fail Mesa-9.1.1 softpipe pass Mesa-9.1.1 nouveau pass Mesa-9.1.1 llvmpipe fail Mesa-git softpipe pass Mesa-git nouveau pass Mesa-git llvmpipe fail http://open.cdash.org/testSummary.php?project=11name=vtkRenderingOpenGLCxx-TestTransformCoordinateUseDoubledate=2013-04-10 Since apitrace does not support OSMesa I did traces with git and softpipe, llvmpipe, and nouveau. http://crab-lab.zool.ohiou.edu/kevin/vtk_apitraces.tar.bz2 signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] OSMesa VTK
My tests of nightly VTK built against nightly OSMesa failed last night. The onscreen builds are fine. The OSMesa build tests now fail with all black output but I haven't found any error message to inform me of what's going on. I know osmesa just switched to Gallium: that is reflected in VTK's LoadOpenGLExtension test output : GL_VERSION: 2.1 Mesa 9.2-devel (git-6173cc1) GL_RENDERER: Mesa OffScreen became GL_VERSION: 2.1 Mesa 9.2.0 (git-f7ef83c) GL_RENDERER: Gallium 0.4 on llvmpipe (LLVM 3.0, 128 bits) Mesa was built : ./autogen.sh \ --prefix=/home/kevin/mesa_nightly \ --enable-glx \ --enable-dri \ --enable-shared-glapi \ --enable-gallium-llvm \ --with-gallium-drivers=nouveau,swrast \ --enable-osmesa signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] OSMesa VTK
On 03/13/2013 10:40 AM, Brian Paul wrote: Can you tell me what the parameters are for your OSMesaCreateContext() and OSMesaMakeCurrent() calls (in particular the image format/type)? I do not know. I'll do some digging into the VTK source and ask on the VTK list. You could also try setting GALLIUM_DRIVER=softpipe and see if the softpipe driver works. The test still fails, however it fails differently, instead of a black image I get a strip of colored snow at the top of the output image... How about I just show you? The output (boring black image) of last night's VTK LoadOpenGLExtension test which used llvmpipe is here : http://open.cdash.org/testDetails.php?test=180871306build=2844006 The output of: $ env GALLIUM_DRIVER=softpipe \ /home/kevin/kitware/VTK_OSMesa_Build/bin/vtkRenderingOpenGLCxxTests \ LoadOpenGLExtension -D /home/kevin/kitware/VTKData \ -T /home/kevin/kitware/VTK_OSMesa_Build/Testing/Temporary \ -V Baseline/Rendering/LoadOpenGLExtension.png is here : http://crab-lab.zool.ohiou.edu/kevin/LoadOpenGLExtension.png signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] OSMesa VTK
Sure: http://crab-lab.zool.ohiou.edu/kevin/vtkRenderingOpenGLCxxTests ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Fix build of swrast only without libdrm
On 03/06/2013 01:54 AM, Michel Dänzer wrote: Actually, you asked for two different software renderers: --with-dri-drivers=swrast produces lib/swrast_dri.so based on classic swrast, --with-gallium-drivers=swrast produces lib/gallium/swrast_dri.so based on llvmpipe/softpipe. Presumably both are built before and after the change(s) in question, they merely changed which one ends up installed / picked up first at runtime. Oh my... I've started building nightly drm as well. (Fedora 17 has libdrm_nouveau2.so which I can't make work.) Now I can test VTK against the much more default (wild type) configuration: export PKG_CONFIG_PATH=/home/kevin/drm_nightly/lib/pkgconfig/ ./autogen.sh \ --prefix=/home/kevin/mesa_nightly \ --enable-glx \ --enable-dri \ --enable-shared-glapi \ --enable-gallium-llvm \ --enable-osmesa signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Fix build of swrast only without libdrm
On 03/04/2013 01:32 PM, Matt Turner wrote: Committed. Thanks! Before this change ( at least this is the most reasonable change from last night ) I would configure mesa with : ./autogen.sh \ --prefix=/home/kevin/mesa_nightly \ --enable-glx \ --with-dri-drivers=swrast \ --with-gallium-drivers=swrast \ --enable-osmesa and according to VTK's LoadOpenGLExtension test in fact I got : http://open.cdash.org/testDetails.php?test=179582680build=2835185 GL_VENDOR: VMware, Inc. GL_VERSION: 2.1 Mesa 9.2-devel (git-b88f74d) GL_RENDERER: Gallium 0.4 on llvmpipe (LLVM 3.0, 128 bits) but today I get : http://open.cdash.org/testDetails.php?test=179722202build=2836181 GL_VENDOR: Mesa Project GL_VERSION: 2.1 Mesa 9.2-devel (git-e21460b) GL_RENDERER: Software Rasterizer so now configure is giving me exactly what I asked for which is good :-) Unfortunately it isn't what I want :-( and the swrast driver gives me more vtk test errors than the llvmpipe driver :-( I have spare cycles on some machines I might be able to test VTK on all of the mesa software renderers and nouveau but for now how do I get the old behavior? configure --help gives me only an example with swrast. ./autogen.sh \ --prefix=/home/kevin/mesa_nightly \ --enable-glx \ --with-gallium-drivers=llvmpipe \ --enable-osmesa Fails: configure: error: Package requirements (libdrm_nouveau = 2.4.33) were not met: On fedora it's : $ cat /usr/lib64/pkgconfig/libdrm_nouveau2.pc | grep Name Name: libdrm_nouveau2 ./autogen.sh \ --prefix=/home/kevin/mesa_nightly \ --enable-glx \ --with-dri-drivers= \ --with-gallium-drivers=llvmpipe \ --enable-osmesa Fails: configure: error: Unknown Gallium driver: llvmpipe signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Fix build of swrast only without libdrm
On 03/05/2013 01:58 PM, Matt Turner wrote: On Tue, Mar 5, 2013 at 9:37 AM, Kevin H. Hobbs hob...@ohio.edu wrote: so now configure is giving me exactly what I asked for which is good :-) Unfortunately it isn't what I want :-( and the swrast driver gives me more vtk test errors than the llvmpipe driver :-( It's what you asked for but not what you wanted? Not sure I can help with that. :) If whatever this problem is is caused by the commit you mention, I have a patch on the list now to fix it. The only software renderer in the output of './configure --help' is swrast. I asked for a software renderer, and I got one, so I didn't notice that I didn't get what I was asking for. I also didn't know the difference between software renderers OSMesa=Xlib=Swrast=llvmpipe... Now, I realize that I was asking for a specific software renderer, and got a different one. The patch discussed in this thread fixed that. There are very few VTK test failures left for the llvmpipe renderer. (None for Xlib and OSMesa wahoo!) I would like to get the llvmpipe VTK test failures to zero, and then add other renderers to my nightly VTK tests. The problem I have is: I do not see any way to configure Mesa to build the llvmpipe driver. signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] VTK Tests fails with Mesa Swrast passes with OSMesa
On 02/19/2013 09:51 AM, Brian Paul wrote: Looks like lines, in particular, are missing. I don't see any recent changes to swrast/osmesa that would seem to cause this. There probably were none. I'm trying to track down long standing issues. 1. You do a git-bisect of mesa to find the regression Since I have no idea when this failure started.. 2. Make an apitrace of the failing test so I can investigate. http://crab-lab.zool.ohiou.edu/kevin/vtk_apitraces.tar.bz2 vtk_apitraces/vtkTraceSwrast.trace fails vtk_apitraces/vtkTraceOSMesa.trace passes signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] VTK Tests fails with Mesa Swrast passes with OSMesa
I have two machines {bubbles, murron} doing nightly dashboard builds of
VTK using nightly Mesa.
Each machine does a build of VTK using swrast and one with OSMesa.
Many tests pass on both machines when using OSMesa and fail on both
machines using swrast.
This is an example :
Test failing on bubbles and murron with swrast
http://open.cdash.org/testDetails.php?test=177420341build=2813128
http://open.cdash.org/testDetails.php?test=177431601build=2813212
Test passing on bubbles and murron with OSMesa
http://open.cdash.org/testDetails.php?test=177404326build=2812997
http://open.cdash.org/testDetails.php?test=177411381build=2813049
Many of the tests fail in a similar way: some of the elements of the
image are just missing.
signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Build fails at hash_table.c
gmake[5]: Entering directory `/home/kevin/mesa/src/glsl/builtin_compiler' gmake[5]: *** No rule to make target `../../../src/mesa/program/hash_table.c', needed by `hash_table.o'. Stop. My mesa build has been failing here for the past few days. The script that does the build is attached but the configuration is: ./autogen.sh \ --prefix=/home/kevin/mesa_nightly \ --enable-glx \ --with-dri-drivers=swrast \ --with-gallium-drivers=swrast \ --enable-osmesa update_mesa.sh Description: application/shellscript signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Build fails at hash_table.c
On 12/10/2012 09:33 AM, Marek Olšák wrote: Type git clean -fdX before building Mesa. Sometimes I hate git. make clean git reset --hard git clean -fd git pull origin isn't enough because if the file was in .gitignore and not cleaned by make clean, then git clean ignored it. I used to use make realclean from the old Makefile days but that's gone. I just tried make distclean ; git clean -ndX, and of course that listed files that are there for configure. And welcome to Mesa's build system, which never really works as expected. I build from git every night just so that there will be a better chance of things working when I want the release version. signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] OSMesa and Shared GLAPI
With shared GLAPI can Mesa be built so that I link the same application to GL and OSMesa and get onscreen rendering (or even accelerated rendering) rendering when I have DISPLAY set and OSMesa rendering when I don't? signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] link error caused by -l -O2
I just checked out mesa from git. My system runs Fedora 17 x86_64. I configured mesa with : $ ./autogen.sh \ --prefix=/home/kevin/mesa_build/ \ --disable-dri \ --enable-glx \ --enable-xlib-glx \ --enable-osmesa \ --without-gallium-drivers and built with : $ make -ij8 make I get : gmake[5]: Entering directory `/home/kevin/mesa/src/mesa/drivers/x11' CCLD libGL.la /usr/bin/ld: cannot find -l-O2 collect2: error: ld returned 1 exit status I ran : $ make SHELL=sh -xv and got: ++ gcc -shared -fPIC -DPIC .libs/fakeglx.o .libs/glxapi.o .libs/xfonts.o .libs/xm_api.o .libs/xm_buffer.o .libs/xm_dd.o .libs/xm_line.o .libs/xm_tri.o -Wl,--whole-archive ../../../../src/mesa/.libs/libmesa.a ../../../../src/mapi/glapi/.libs/libglapi.a -Wl,--no-whole-archive -lX11 -lXext -lm -lpthread -ldl -L../../../../lib -l -O2 -Wl,-soname -Wl,libGL.so.1 -o .libs/libGL.so.1.6.0 /usr/bin/ld: cannot find -l-O2 collect2: error: ld returned 1 exit status I find the -l -O2 suspicious. signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] link error caused by -l -O2
On 08/14/2012 06:59 PM, Matt Turner wrote: Ian says (and I agree) that shared-glapi doesn't make any sense for non-DRI configurations. So build with --disable-shared-glapi until I get a patch to disable it on Xlib/OSMesa/... Thank you. --disable-shared-glapi allows the build to proceed. signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Config fails on Radeon
Config of the git repository fails because it can't find Radeon libraries This is despite the configure line being : ./autogen.sh \ --prefix=/home/kevin/mesa_xlib/ \ --disable-dri \ --enable-glx \ --enable-xlib-glx \ --disable-osmesa checking for RADEON... no configure: error: Package requirements (libdrm_radeon = 2.4.31) were not met: Requested 'libdrm_radeon = 2.4.31' but version of libdrm_radeon is 2.4.26 Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables RADEON_CFLAGS and RADEON_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Config fails on Radeon
On 02/08/2012 07:43 AM, Kenneth Graunke wrote: On 02/08/2012 04:28 AM, Kevin H. Hobbs wrote: configure: error: Package requirements (libdrm_radeon= 2.4.31) were not met: Does it work if you add --with-gallium-drivers='' as well? It does. It also looks like --with-gallium-drivers='swrast' works too. I've added that to my nightly scripts. I would like to test as much as I can, while testing what I need to. I don't want testing tunnel vision. signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] OSMesa glapi linlking
On 01/31/2012 11:14 AM, Matt Turner wrote: You cannot change branches or bisect without running autogen.sh (and maybe git clean to be safe). I see glsl_lexer.cc in your log, which exists only in the master branch. Sorry, I left a lot out, but I can't be certain I did enough cleaning so : $ ./mesa_thurough_cross_branch_build_check.sh \ mesa_thurough_cross_branch_build_check.out 21 http://crab-lab.zool.ohiou.edu/kevin/mesa_thurough_cross_branch_build_check.tar.bz2 Ackk gotta go... signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] OSMesa glapi linlking
On 01/31/2012 09:53 AM, Brian Paul wrote: I just pushed a couple osmesa fixes to master and the 8.0 branch. Can you give it a try? Thinks seem to fix things on the 8.0 branch but I'm unable to verify on master due to some other regressions ATM. -Brian master leaves a bunch of symbols undefined. /home/kevin/mesa_osmesa/lib/libglsl.so: undefined reference to `_mesa_symbol_table_ctor' /home/kevin/mesa_osmesa/lib/libOSMesa.so.8: undefined reference to `_swrast_unmap_soft_renderbuffer' /home/kevin/mesa_osmesa/lib/libOSMesa.so.8: undefined reference to `_tnl_InvalidateState' /home/kevin/mesa_osmesa/lib/libOSMesa.so.8: undefined reference to `_swrast_map_soft_renderbuffer' 8.0 mostly works 98% tests passed, 9 tests failed out of 596 Total Test time (real) = 259.19 sec The following tests FAILED: 259 - TestMultiTexturing (SEGFAULT) 260 - TestMultiTexturingTransform (SEGFAULT) 262 - TestScalarBar (Failed) 330 - TestBarChartActor (Failed) 334 - TestPieChartActor (Failed) 338 - TestLegendBoxActor (Failed) 380 - TestBrokenLineWidget (Failed) 510 - Infovis-TestTulipReaderClusters (Failed) 536 - Views-TestRenderView (Failed) signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] OSMesa glapi linlking
On 01/25/2012 05:20 PM, Jon TURNEY wrote: ... and reverting always build shared glapi didn't wrap this line above in ifeq ($(SHARED_GLAPI),1)/endif, since it wasn't there before. Sigh. I guess you could try the attached. $ git apply ~/Download/0001-Don-t-try-to-link-OSMesa-with-shared-glapi-unless-sh.patch /home/kevin/Download/0001-Don-t-try-to-link-OSMesa-with-shared-glapi-unless-sh.patch:24: trailing whitespace. ifeq ($(SHARED_GLAPI),1) /home/kevin/Download/0001-Don-t-try-to-link-OSMesa-with-shared-glapi-unless-sh.patch:26: trailing whitespace. endif error: patch failed: src/mesa/drivers/osmesa/Makefile:25 error: src/mesa/drivers/osmesa/Makefile: patch does not apply I tried with just the lines added manually and almost every VTK test gives me: osmesa.c:892: OSMesaMakeCurrent: Assertion `osmesa-srb-Base.RefCount == 2' failed. signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Segmentation fault with VTK OffScreenRendering
On 01/30/2012 02:13 PM, Joshua Daniel Franklin (UW Seattle) wrote: On 1/27/12 12:28 PM, Kevin H. Hobbs wrote: So you want to get OSMesa from Mesa-7.11.2 working with VTK-5.8.0 on Fedora 15? So is it EGL that has trouble with offline rendering, since you did --disable-egl? No. it's just other stuff that isn't OSMesa. It's too bad since I guess that means stock Fedora users are stuck using X11. The mesa.spec from Fedora 15 does this: They shouldn't be (at least not anymore) : sudo yum install mesa-libOSMesa mesa-libOSMesa-devel cd /tmp/VTK_Build rm -rf * cmake \ -DVTK_DATA_ROOT:PATH=/tmp/VTKData \ -DOPENGL_INCLUDE_DIR:PATH=/usr/include \ -DOPENGL_gl_LIBRARY:FILEPATH= \ -DOPENGL_glu_LIBRARY:FILEPATH=/usr/lib64/libGLU.so \ -DVTK_OPENGL_HAS_OSMESA:BOOL=ON \ -DOSMESA_INCLUDE_DIR:PATH=/usr/include \ -DOSMESA_LIBRARY:FILEPATH=/usr/lib64/libOSMesa.so \ -DVTK_USE_OFFSCREEN:BOOL=ON \ -DVTK_USE_X:BOOL=OFF \ /tmp/VTK make -j4 make test I'm trying that now but you can give it a shot before then. signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Segmentation fault with VTK OffScreenRendering
On 01/30/2012 02:53 PM, Kevin H. Hobbs wrote: I'm trying that now but you can give it a shot before then. The VTK tests have the same pattern of failures with the Fedora 15 OSMesa package as with the custom built OSMesa library, that is : The following tests FAILED: 146 - TestTecplotReader (Failed) 203 - TestMultiTexturing (SEGFAULT) 204 - TestMultiTexturingTransform (SEGFAULT) signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Segmentation fault with VTK OffScreenRendering
So you want to get OSMesa from Mesa-7.11.2 working with VTK-5.8.0 on Fedora 15? You can do without the VTKData lines. They don't add as many tests as I thought. # Go somewhere to play around cd /tmp # get Mesa wget ftp://ftp.freedesktop.org/pub/mesa/7.11.2/MesaLib-7.11.2.tar.bz2 # get VTK and test data wget http://www.vtk.org/files/release/5.8/vtk-5.8.0.tar.gz wget http://www.vtk.org/files/release/5.8/vtkdata-5.8.0.tar.gz # untar Mesa tar -xjvf MesaLib-7.11.2.tar.bz2 # Configure and build mesa cd Mesa-7.11.2/ ./configure \ --with-driver=osmesa \ --with-gallium-drivers= \ --disable-egl make -j4 cd .. # Untar VTK and VTKData tar -xzvf vtk-5.8.0.tar.gz tar -xzvf vtkdata-5.8.0.tar.gz # Configure and build VTK mkdir VTK_Build cd VTK_Build/ cmake \ -DVTK_DATA_ROOT:PATH=/tmp/VTKData \ -DOPENGL_INCLUDE_DIR:PATH=/tmp/Mesa-7.11.2/include \ -DOPENGL_gl_LIBRARY:FILEPATH= \ -DOPENGL_glu_LIBRARY:FILEPATH=/tmp/Mesa-7.11.2/lib/libGLU.so \ -DVTK_OPENGL_HAS_OSMESA:BOOL=ON \ -DOSMESA_INCLUDE_DIR:PATH=/tmp/Mesa-7.11.2/include \ -DOSMESA_LIBRARY:FILEPATH=/tmp/Mesa-7.11.2/lib/libOSMesa.so \ -DVTK_USE_OFFSCREEN:BOOL=ON \ -DVTK_USE_X:BOOL=OFF \ /tmp/VTK make -j4 make test When I run this I get only three test failures out of 463. The following tests FAILED: 146 - TestTecplotReader (Failed) 203 - TestMultiTexturing (SEGFAULT) 204 - TestMultiTexturingTransform (SEGFAULT) signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] OSMesa glapi linlking
My build of OSMesa from git is failing: ./autogen.sh \ --prefix=/home/kevin/mesa_osmesa/ \ --disable-dri \ --disable-glx \ --enable-osmesa /bin/sh ../../../../bin/mklib -o OSMesa -linker 'g++' -ldflags '' \ -major 8 -minor 0 -patch 0 \ -install ../../../../lib -cplusplus \ -id /home/kevin/mesa_osmesa/lib/libOSMesa.8.dylib \ -L../../../../lib -lglapi -L../../../../lib -lm -lpthread -ldl osmesa.o ../../../../src/mesa/libmesa.a ../../../../src/mapi/glapi/libglapi.a ../../../../src/glsl/libglsl.a mklib: Making Linux shared library: libOSMesa.so.8.0.0 /usr/bin/ld: cannot find -lglapi signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] OSMesa glapi linlking
On 01/25/2012 11:58 AM, Matt Turner wrote: On Wed, Jan 25, 2012 at 11:40 AM, Kevin H. Hobbs hob...@ohio.edu wrote: My build of OSMesa from git is failing: ./autogen.sh \ --prefix=/home/kevin/mesa_osmesa/ \ --disable-dri \ --disable-glx \ --enable-osmesa Unrelated (related to another thread recently) but, did you mean to build Gallium (and whatever drivers configure determined your system could build)? If you didn't want Gallium, you should use --with-gallium-drivers= I don't really care. It isn't enough time for me to worry about. If building more than I want detects more errors then I consider that ok. /bin/sh ../../../../bin/mklib -o OSMesa -linker 'g++' -ldflags '' \ -major 8 -minor 0 -patch 0 \ -install ../../../../lib -cplusplus \ -id /home/kevin/mesa_osmesa/lib/libOSMesa.8.dylib \ -L../../../../lib -lglapi -L../../../../lib -lm -lpthread -ldl osmesa.o ../../../../src/mesa/libmesa.a ../../../../src/mapi/glapi/libglapi.a ../../../../src/glsl/libglsl.a mklib: Making Linux shared library: libOSMesa.so.8.0.0 /usr/bin/ld: cannot find -lglapi What git hash did you use? I can't reproduce this. The top of git log is : 422b18794eacc8f0be5b4e9611e2726f4e0d86b6 As with most Mesa build errors, you should do a `make clean` or `git clean -dfx`. I haven't touched the directory since I found the error in the log. My full script does : #!/bin/bash rm -rf /home/kevin/mesa_xlib/* rm -rf /home/kevin/mesa_osmesa/* # Update Mesa Source cd /home/kevin/mesa make realclean git reset --hard git pull origin # Make Mesa Xlib ./autogen.sh \ --prefix=/home/kevin/mesa_xlib/ \ --disable-dri \ --enable-glx \ --enable-xlib-glx \ --disable-osmesa make -j8 make install # Make Mesa OSMesa make realclean ./autogen.sh \ --prefix=/home/kevin/mesa_osmesa/ \ --disable-dri \ --disable-glx \ --enable-osmesa make -j8 make install I just ran : rm -rf /home/kevin/mesa_osmesa/* make realclean git reset --hard git pull origin ./autogen.sh \ --prefix=/home/kevin/mesa_osmesa/ \ --disable-dri \ --disable-glx \ --enable-osmesa make -ij8 make and I get the same error : /bin/sh ../../../../bin/mklib -o OSMesa -linker 'g++' -ldflags '' \ -major 8 -minor 0 -patch 0 \ -install ../../../../lib -cplusplus \ -id /home/kevin/mesa_osmesa/lib/libOSMesa.8.dylib \ -L../../../../lib -lglapi -L../../../../lib -lm -lpthread -ldl osmesa.o ../../../../src/mesa/libmesa.a ../../../../src/mapi/glapi/libglapi.a ../../../../src/glsl/libglsl.a mklib: Making Linux shared library: libOSMesa.so.8.0.0 /usr/bin/ld: cannot find -lglapi What I see is : -L../../../../lib -lglapi and ../../../../src/mapi/glapi I see : find ./ -name libglapi* ./src/mapi/glapi/libglapi.a Which isn't anywhere that the linker can find it Links lib/libOSMesa.so* are created but they point to a non-existant libOSMesa.so.8.0.0 signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] OSMesa glapi linlking
On 01/25/2012 02:03 PM, Matt Turner wrote: On Wed, Jan 25, 2012 at 1:42 PM, Kevin H. Hobbs hob...@ohio.edu wrote: Maybe try reverting 4e5a8937d1a1bfb2a3bd067ed01e036728675fc2? So this change is just the line OSMESA_LIB_DEPS := -L$(TOP)/$(LIB_DIR) -l$(GLAPI_LIB) $(OSMESA_LIB_DEPS) So I commented that out. I now get an OSMesa library. I do not get a shared libglapi.so in lib nor is one installed in the install step. Now for the test... My OSMesa VTK builds but I get a bunch of these : GraphicsCxxTests: osmesa.c:892: OSMesaMakeCurrent: Assertion `osmesa-srb-Base.RefCount == 2' failed. end of output Test time = 0.04 sec signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Segmentation fault with VTK OffScreenRendering
On 01/24/2012 06:11 PM, Joshua Daniel Franklin (UW Seattle) wrote: The application works fine with an X11 DISPLAY using hardware GL but crashes when we try to use Mesa only. I decided to go to the very basic VTK_OPENGL_HAS_OSMESA OffScreenRendering.cxx example: I will gladly help you, but it's been a long day and I'm not prepared to right now. signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] broken --enable-xlib-glx build
On 01/20/2012 06:12 PM, Brian Paul wrote: $ glxinfo name of display: :0.0 glxinfo: symbol lookup error: /home/brian/mesa/lib/libGL.so.1: undefined symbol: u_tsd_set My nightly builds of VTK and ParaView built with OSMesa or xlib OSMesa are broken this way too. Their mesa's are built with: ./autogen.sh \ --prefix=/home/kevin/mesa_xlib/ \ --disable-dri \ --enable-glx \ --enable-xlib-glx \ --disable-osmesa or ./autogen.sh \ --prefix=/home/kevin/mesa_osmesa/ \ --disable-dri \ --disable-glx \ --enable-osmesa signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Friday Night Segfaults
I build Mesa OSMesa and xlib from git every night, and then I build and test VTK and ParaView against both Mesa libraries all of this on 9 hosts. Beginning Friday night basically all of the rendering tests started failing with a solid color on OSMesa and segfaulting with xlib. I suspect Mesa because my builds seem to be the only ones on the VTK/PV dashboards that suddenly had +300 test failures and I'm the only person nutty enough to test VTK/PV with Mesa from git. I'm rebuilding in debug now to try and track down the segfault, but somebody might have an idea now. signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Friday Night Segfaults
On 11/07/2011 03:29 PM, Kevin H. Hobbs wrote: I build Mesa OSMesa and xlib from git every night, and then I build and test VTK and ParaView against both Mesa libraries all of this on 9 hosts. Beginning Friday night basically all of the rendering tests started failing with a solid color on OSMesa and segfaulting with xlib. I suspect Mesa because my builds seem to be the only ones on the VTK/PV dashboards that suddenly had +300 test failures and I'm the only person nutty enough to test VTK/PV with Mesa from git. I'm rebuilding in debug now to try and track down the segfault, but somebody might have an idea now. One run of a segfaulting test and my gdb session follows: [kevin@bubbles VTK_Xlib_Build]$ /home/kevin/kitware/VTK_Xlib_Build/bin/GraphicsCxxTests BoxClipPolyData -D /home/kevin/kitware/VTKData -T /home/kevin/kitware/VTK_Xlib_Build/Testing/Temporary -V Baseline/Graphics/BoxClipPolyData.png Segmentation fault [kevin@bubbles VTK_Xlib_Build]$ gdb /home/kevin/kitware/VTK_Xlib_Build/bin/GraphicsCxxTests GNU gdb (GDB) Fedora (7.2-51.fc14) Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-redhat-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /home/kevin/kitware/VTK_Xlib_Build/bin/GraphicsCxxTests...done. (gdb) run BoxClipPolyData -D /home/kevin/kitware/VTKData -T /home/kevin/kitware/VTK_Xlib_Build/Testing/Temporary -V Baseline/Graphics/BoxClipPolyData.png Starting program: /home/kevin/kitware/VTK_Xlib_Build/bin/GraphicsCxxTests BoxClipPolyData -D /home/kevin/kitware/VTKData -T /home/kevin/kitware/VTK_Xlib_Build/Testing/Temporary -V Baseline/Graphics/BoxClipPolyData.png [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. unpack_RGBA (src=0x0, dst=0x7ffbcd60) at main/format_unpack.c:66 66 const GLuint s = *((const GLuint *) src); Missing separate debuginfos, use: debuginfo-install libICE-1.0.6-2.fc13.x86_64 libSM-1.1.0-7.fc12.x86_64 libX11-1.3.4-4.fc14.x86_64 libXau-1.0.6-1.fc14.x86_64 libXext-1.1.2-2.fc14.x86_64 libXt-1.0.7-1.fc13.x86_64 libuuid-2.18-4.8.fc14.x86_64 libxcb-1.7-1.fc14.x86_64 (gdb) bt #0 unpack_RGBA (src=0x0, dst=0x7ffbcd60) at main/format_unpack.c:66 #1 0x765363db in _mesa_unpack_rgba_row (format=value optimized out, n=800, src=value optimized out, dst=value optimized out) at main/format_unpack.c:1256 #2 0x76526d34 in slow_read_rgba_pixels (ctx=0x8599a0, x=value optimized out, y=value optimized out, width=800, height=640, format=6407, type=5121, pixels=0xd28ce0, packing=0x7fffce10, transferOps=2048) at swrast/s_readpix.c:251 #3 0x765271fa in read_rgba_pixels (ctx=0x8599a0, x=0, y=0, width=800, height=640, format=6407, type=5121, packing=0x869238, pixels=0xd28ce0) at swrast/s_readpix.c:296 #4 _swrast_ReadPixels (ctx=0x8599a0, x=0, y=0, width=800, height=640, format=6407, type=5121, packing=0x869238, pixels=0xd28ce0) at swrast/s_readpix.c:508 #5 0x763ad097 in _mesa_ReadnPixelsARB (x=0, y=0, width=800, height=640, format=6407, type=5121, bufSize=2147483647, pixels=0xd28ce0) at main/readpix.c:269 #6 0x763ad2aa in _mesa_ReadPixels (x=value optimized out, y=value optimized out, width=value optimized out, height=value optimized out, format=value optimized out, type=value optimized out, pixels=0xd28ce0) at main/readpix.c:277 #7 0x77b1a992 in vtkOpenGLRenderWindow::GetPixelData (this=0x6edf90, x1=0, y1=0, x2=799, y2=639, front=0, data=0xd28ce0 \030r9T6) at /home/kevin/kitware/VTK/Rendering/vtkOpenGLRenderWindow.cxx:543 #8 0x77b1a610 in vtkOpenGLRenderWindow::GetPixelData (this=0x6edf90, x1=0, y1=0, x2=799, y2=639, front=0) at /home/kevin/kitware/VTK/Rendering/vtkOpenGLRenderWindow.cxx:412 #9 0x77aba8c5 in vtkWindowToImageFilter::RequestData (this=0xb85bf0, outputVector=0x82cb00) at /home/kevin/kitware/VTK/Rendering/vtkWindowToImageFilter.cxx:431 #10 0x77ab925a in vtkWindowToImageFilter::ProcessRequest (this=0xb85bf0, request=0xb8b800, inputVector=0x0, outputVector=0x82cb00) at /home/kevin/kitware/VTK/Rendering/vtkWindowToImageFilter.cxx:203 #11 0x74af6aa9 in vtkExecutive::CallAlgorithm (this=0xb841a0, request=0xb8b800, direction=1, inInfo=0x0, outInfo=0x82cb00) at /home/kevin/kitware/VTK/Filtering/vtkExecutive.cxx:747 #12 0x74adecc4 in vtkDemandDrivenPipeline::ExecuteData (this=0xb841a0, request=0xb8b800, inInfo=0x0, outInfo=0x82cb00) at /home/kevin/kitware/VTK/Filtering/vtkDemandDrivenPipeline.cxx:507 #13 0x74ade352 in vtkDemandDrivenPipeline::ProcessRequest (this=0xb841a0, request=0xb8b800, inInfoVec=0x0, outInfoVec=0x82cb00
Re: [Mesa-dev] Friday Night Segfaults
On 11/07/2011 03:29 PM, Kevin H. Hobbs wrote: I build Mesa OSMesa and xlib from git every night, and then I build and test VTK and ParaView against both Mesa libraries all of this on 9 hosts. Beginning Friday night basically all of the rendering tests started failing with a solid color on OSMesa and segfaulting with xlib. I suspect Mesa because my builds seem to be the only ones on the VTK/PV dashboards that suddenly had +300 test failures and I'm the only person nutty enough to test VTK/PV with Mesa from git. I'm rebuilding in debug now to try and track down the segfault, but somebody might have an idea now. The rendering happens, and looks basically correct but the trouble seems to happen when VTK grabs the image from the the render window. Eric could these be your changes near glReadPixels? signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Friday Night Segfaults
On 11/07/2011 04:21 PM, Brian Paul wrote: As I posted on Friday, glReadPixels is broken. I have a patch that will probably fix most of this. I'll push it soon. -Brian OK, I'm sorry for the noise. I didn't make the connection at the time, though I should have since I knew the VTK tests use glReadPixels. signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 7.11 and osmesa
On 10/07/2011 10:53 AM, Paul Gotzel wrote: Brain, I'm using osmesa with VTK and in this particular test I'm rendering just lines. The ratios stay the same for just triangles. Just for these simple primitives 7.11 seems to be about 4 times slower that 7.6.1. These builds on the VTK dashboard use a nightly build of OSMesa from git : http://www.cdash.org/CDash/index.php?project=VTKfiltercount=1showfilters=1field1=buildname/stringcompare1=63value1=OSMesa If there is a particularly relevant test the timing data might show the change. signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 7.11 and osmesa
On 10/07/2011 12:10 PM, Kevin H. Hobbs wrote: On 10/07/2011 10:53 AM, Paul Gotzel wrote: Brain, I'm using osmesa with VTK and in this particular test I'm rendering just lines. The ratios stay the same for just triangles. Just for these simple primitives 7.11 seems to be about 4 times slower that 7.6.1. These builds on the VTK dashboard use a nightly build of OSMesa from git : http://www.cdash.org/CDash/index.php?project=VTKfiltercount=1showfilters=1field1=buildname/stringcompare1=63value1=OSMesa If there is a particularly relevant test the timing data might show the change. In particular I see what might be a timing increase around in late July here : http://www.cdash.org/CDash/testDetails.php?test=118152795build=1601123 and : http://www.cdash.org/CDash/testDetails.php?test=118152797build=1601123 Although I don't know how much actual line rendering is in these tests. signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] OSMesa VTK Test Segfault
I build VTK from git with Mesa from git every night. mesa is built with : ./autogen.sh \ --prefix=/home/kevin/mesa_osmesa/ \ --with-driver=osmesa \ --disable-gallium VTK is linked to OSMesa only and no other GL. VTK's Charts-TestMultipleScalarsToColors test is segfaulting. The backtrace from gdb is : #0 glGetString () at glapi_x86-64.S:9876 #1 0x76031cd7 in vtkOpenGLExtensionManager::ExtensionSupported (this=0x654b50, name=0x41d7f6 GL_VERSION_1_2) at /home/kevin/kitware/VTK/Rendering/vtkOpenGLExtensionManager.cxx:204 #2 0x004162d5 in TestMultipleScalarsToColors () at /home/kevin/kitware/VTK/Charts/Testing/Cxx/TestMultipleScalarsToColors.cxx:47 #3 0x0040e5db in main (ac=9, av=0x7fffdb00) at /home/kevin/kitware/VTK_OSMesa_Build/Charts/Testing/Cxx/ChartsCxxTests.cxx:288 The output from valgrind is : $ valgrind /home/kevin/kitware/VTK_OSMesa_Build/bin/ChartsCxxTests TestMultipleScalarsToColors -D /home/kevin/kitware/VTKData -T /home/kevin/kitware/VTK_OSMesa_Build/Testing/Temporary -V Baseline/Charts/TestMultipleScalarsToColors.png -E 25 ==28040== Memcheck, a memory error detector ==28040== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==28040== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==28040== Command: /home/kevin/kitware/VTK_OSMesa_Build/bin/ChartsCxxTests TestMultipleScalarsToColors -D /home/kevin/kitware/VTKData -T /home/kevin/kitware/VTK_OSMesa_Build/Testing/Temporary -V Baseline/Charts/TestMultipleScalarsToColors.png -E 25 ==28040== ==28040== Invalid read of size 8 ==28040==at 0xB571A07: glGetString (glapi_x86-64.S:9876) ==28040==by 0x4162D4: TestMultipleScalarsToColors(int, char**) (TestMultipleScalarsToColors.cxx:47) ==28040==by 0x40E5DA: main (ChartsCxxTests.cxx:288) ==28040== Address 0x898 is not stack'd, malloc'd or (recently) free'd ==28040== ==28040== ==28040== Process terminating with default action of signal 11 (SIGSEGV) ==28040== Access not within mapped region at address 0x898 ==28040==at 0xB571A07: glGetString (glapi_x86-64.S:9876) ==28040==by 0x4162D4: TestMultipleScalarsToColors(int, char**) (TestMultipleScalarsToColors.cxx:47) ==28040==by 0x40E5DA: main (ChartsCxxTests.cxx:288) ==28040== If you believe this happened as a result of a stack ==28040== overflow in your program's main thread (unlikely but ==28040== possible), you can try to increase the size of the ==28040== main thread stack using the --main-stacksize= flag. ==28040== The main thread stack size used in this run was 10485760. ==28040== Invalid free() / delete / delete[] ==28040==at 0x4A04D72: free (vg_replace_malloc.c:325) ==28040==by 0x318532735A: ??? (in /lib64/libc-2.11.2.so) ==28040==by 0x3185326EF1: ??? (in /lib64/libc-2.11.2.so) ==28040==by 0x480162B: _vgnU_freeres (vg_preloaded.c:62) ==28040==by 0x6AC9CD6: vtkOpenGLExtensionManager::ExtensionSupported(char const*) (vtkOpenGLExtensionManager.cxx:204) ==28040==by 0x4162D4: TestMultipleScalarsToColors(int, char**) (TestMultipleScalarsToColors.cxx:47) ==28040==by 0x40E5DA: main (ChartsCxxTests.cxx:288) ==28040== Address 0xb38ca10 is not stack'd, malloc'd or (recently) free'd ==28040== ==28040== ==28040== HEAP SUMMARY: ==28040== in use at exit: 168,234 bytes in 1,731 blocks ==28040== total heap usage: 1,806 allocs, 77 frees, 189,825 bytes allocated ==28040== ==28040== LEAK SUMMARY: ==28040==definitely lost: 0 bytes in 0 blocks ==28040==indirectly lost: 0 bytes in 0 blocks ==28040== possibly lost: 10,645 bytes in 112 blocks ==28040==still reachable: 157,589 bytes in 1,619 blocks ==28040== suppressed: 0 bytes in 0 blocks ==28040== Rerun with --leak-check=full to see details of leaked memory ==28040== ==28040== For counts of detected and suppressed errors, rerun with: -v ==28040== ERROR SUMMARY: 3 errors from 2 contexts (suppressed: 6 from 6) Segmentation fault Could this be a problem in Mesa? signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Xlib GL needs -ltalloc
On 08/27/2010 02:45 PM, Jon TURNEY wrote: Updated patch attached. No luck, I still get : /home/kevin/mesa_xlib/lib/libGL.so: undefined reference to `talloc_strdup' and such when I link an application against libGL.so and there is no talloc in the output of 'ldd libGL.so'. sgall...@redhat.com said to me : My guess is that you're running afoul of the changes in the linker. It used to be that the linker would implicitly link against the dependencies of anything you linked with. Now it has to be explicit. Is this even something Mesa can fix? Other dependencies are pulled in though. signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] 7.8.3 release
On 08/24/2010 10:53 AM, tom fogal wrote: Brian Paul bri...@vmware.com writes: One thing: was the issue with libGL + libOSMesa linking relevant to the 7.8 branch? I don't remember. It was, but it was relevant to all branches. The solution I came to was that mangling would solve the immediate problem, but VTK's mangling setup is broken so we couldn't be 100% sure on that. Anyway I'm pretty convinced that my project still has some issues there, but nothing new, so I'm alright backburnering it for now. Kevin has a workaround for his issue, AFAIK. I do have a workaround. I basically add everything from mesa/src/mesa/drivers/osmesa/Makefile into mesa/src/mesa/drivers/x11/Makefile and tell VTK to use libGL.so for GL and OSMesa. But for now I'm submitting VTK dashboard builds for : GL (xlib) only OSMesa only and GL (xlib) plus mangled OSMesa to see if any fruit falls from the tree. signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] OSMesa needs -ltalloc
When I do : ./autogen.sh --with-driver=osmesa make -j8 nm lib/libOSMesa.so | grep talloc I get : 00160a30 T _ZN9glsl_type20init_talloc_type_ctxEv 00298220 r _ZZN9glsl_type20init_talloc_type_ctxEvE19__PRETTY_FUNCTION__ U _talloc_array U _talloc_free U _talloc_reference_loc U _talloc_set_destructor U _talloc_steal_loc U _talloc_zero U _talloc_zero_array U talloc_asprintf U talloc_asprintf_append U talloc_init U talloc_named_const U talloc_parent U talloc_strdup U talloc_strdup_append U talloc_strndup U talloc_strndup_append U talloc_unlink U talloc_vasprintf_append That is there are undefined talloc symbols in libGL. which wouldn't be a problem if : ldd lib/libOSMesa.so | grep talloc had any reference to talloc. However when I do : ./autogen.sh --with-driver=dri make -j8 for sofile in `find ./ -name *.so` do talloclines=`ldd $sofile | grep -c talloc` if [ $talloclines -ge 1 ] then echo $sofile fi done I get : ./src/gallium/targets/dri-swrast/swrastg_dri.so ./src/mesa/drivers/dri/mach64/mach64_dri.so ./src/mesa/drivers/dri/unichrome/unichrome_dri.so ./src/mesa/drivers/dri/r200/r200_dri.so ./src/mesa/drivers/dri/r128/r128_dri.so ./src/mesa/drivers/dri/swrast/swrast_dri.so ./src/mesa/drivers/dri/tdfx/tdfx_dri.so ./src/mesa/drivers/dri/i915/i915_dri.so ./src/mesa/drivers/dri/r600/r600_dri.so ./src/mesa/drivers/dri/i965/i965_dri.so ./src/mesa/drivers/dri/radeon/radeon_dri.so ./src/mesa/drivers/dri/mga/mga_dri.so ./src/mesa/drivers/dri/r300/r300_dri.so ./src/mesa/drivers/dri/savage/savage_dri.so ./lib/tdfx_dri.so ./lib/gallium/swrastg_dri.so ./lib/radeon_dri.so ./lib/r200_dri.so ./lib/r600_dri.so ./lib/r300_dri.so ./lib/mach64_dri.so ./lib/r128_dri.so ./lib/swrast_dri.so ./lib/i965_dri.so ./lib/egl/st_GL.so ./lib/mga_dri.so ./lib/unichrome_dri.so ./lib/i915_dri.so ./lib/savage_dri.so It looks like OSMesa is getting left out in the cold since the GLSL2 merge. signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Talloc
Mesa git started failing to configure early this week. I ran ./autogen.sh \ --with-driver=xlib \ --disable-gallium and configure complained about missing talloc. I looked and saw that my fedora 12 machine has libtalloc installed but libtalloc-devel was not installed, so I installed it. That got rid of the configure warning, and mesa built without issue, but when I try to link an application to GL I get : /home/kevin/mesa/lib/libGL.so.1: undefined reference to `talloc_strdup' /home/kevin/mesa/lib/libGL.so.1: undefined reference to `_talloc_array' /home/kevin/mesa/lib/libGL.so.1: undefined reference to `_talloc_free' /home/kevin/mesa/lib/libGL.so.1: undefined reference to `talloc_strdup_append' /home/kevin/mesa/lib/libGL.so.1: undefined reference to `talloc_asprintf' /home/kevin/mesa/lib/libGL.so.1: undefined reference to `talloc_init' /home/kevin/mesa/lib/libGL.so.1: undefined reference to `talloc_unlink' /home/kevin/mesa/lib/libGL.so.1: undefined reference to `_talloc_zero' /home/kevin/mesa/lib/libGL.so.1: undefined reference to `talloc_strndup_append' /home/kevin/mesa/lib/libGL.so.1: undefined reference to `_talloc_set_destructor' /home/kevin/mesa/lib/libGL.so.1: undefined reference to `talloc_asprintf_append' /home/kevin/mesa/lib/libGL.so.1: undefined reference to `talloc_vasprintf_append' /home/kevin/mesa/lib/libGL.so.1: undefined reference to `_talloc_reference_loc' /home/kevin/mesa/lib/libGL.so.1: undefined reference to `_talloc_steal_loc' /home/kevin/mesa/lib/libGL.so.1: undefined reference to `talloc_parent' /home/kevin/mesa/lib/libGL.so.1: undefined reference to `talloc_named_const' $ ldd lib/libGL.so linux-vdso.so.1 = (0x7fffae0bb000) libX11.so.6 = /usr/lib64/libX11.so.6 (0x7f1628641000) libXext.so.6 = /usr/lib64/libXext.so.6 (0x7f162842e000) libm.so.6 = /lib64/libm.so.6 (0x7f16281aa000) libpthread.so.0 = /lib64/libpthread.so.0 (0x7f1627f8e000) libgcc_s.so.1 = /lib64/libgcc_s.so.1 (0x7f1627d77000) libc.so.6 = /lib64/libc.so.6 (0x7f16279fe000) libxcb.so.1 = /usr/lib64/libxcb.so.1 (0x7f16277e3000) libdl.so.2 = /lib64/libdl.so.2 (0x7f16275de000) /lib64/ld-linux-x86-64.so.2 (0x003184e0) libXau.so.6 = /usr/lib64/libXau.so.6 (0x7f16273db000) $ nm lib/libGL.so | grep talloc 001ac020 T _ZN9glsl_type20init_talloc_type_ctxEv 002eb820 r _ZZN9glsl_type20init_talloc_type_ctxEvE19__PRETTY_FUNCTION__ U _talloc_array U _talloc_free U _talloc_reference_loc U _talloc_set_destructor U _talloc_steal_loc U _talloc_zero U talloc_asprintf U talloc_asprintf_append U talloc_init U talloc_named_const U talloc_parent U talloc_strdup U talloc_strdup_append U talloc_strndup_append U talloc_unlink U talloc_vasprintf_append My system talloc has no symbols $ nm /usr/lib64/libtalloc.so nm: /usr/lib64/libtalloc.so: no symbols Mesa has a src/talloc with talloc.c and talloc.h signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] VTK Offscreen Segfaults
On 08/11/2010 11:55 PM, tom fogal wrote: Dan Nicholson dbn.li...@gmail.com writes: [snip] So, sorry for not reading the whole thread, but is GL being linked because it's needed by the app, because pkg-config said so, or because the linker added it? It's needed by the app. Not really, it's not used at runtime, but needed at link time because the app has glX* codepaths. Those paths are never taken in the case of the test program. Via another thread, it turns out Kevin *wasn't* using Mesa's mangling support, so we're waiting to hear back on that. I've hit similar weirdness even *with* mangling though, so I'm kind of hoping Kevin still hits it, because I never had a good reproducer and my software stack was larger. -tom I'll try name mangling when I get to work. signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] VTK Offscreen Segfaults
On 08/06/2010 05:20 PM, tom fogal wrote: Well, it does appear to be some type of symbol resolution/overloading issue. However it seems to be with internal Mesa symbols. Switching to a single library -- that is, putting OSMesaCreateContext, etc. into libGL directly, and getting rid of libOSMesa altogether -- seems like it would be the solution, but I imagine there's some reason that's not happening already. Just for grins this morning I added basically everything in mesa/src/mesa/drivers/osmesa/Makefile to mesa/src/mesa/drivers/x11/Makefile The diff is attached. I built VTK with : OPENGL_gl_LIBRARY:FILEPATH=/home/kevin/mesa/lib/libGL.so OSMESA_LIBRARY:FILEPATH=/home/kevin/mesa/lib/libGL.so The VTK's TestOSConeCxx now passes along with 6 of the other tests that were failing. For ParaView this change made the failing test count go from 161 failed tests out of 1001 to 12 tests failed out of 1001. diff --git a/src/mesa/drivers/x11/Makefile b/src/mesa/drivers/x11/Makefile index b5b0c1f..17d1cab 100644 --- a/src/mesa/drivers/x11/Makefile +++ b/src/mesa/drivers/x11/Makefile @@ -34,7 +34,8 @@ SOURCES = \ xm_image.c \ xm_line.c \ xm_span.c \ - xm_tri.c + xm_tri.c \ + $(TOP)/src/mesa/drivers/osmesa/osmesa.c OBJECTS = $(SOURCES:.c=.o) @@ -45,9 +46,11 @@ INCLUDE_DIRS = \ -I$(TOP)/src/mesa/main \ $(X11_INCLUDES) -CORE_MESA = $(TOP)/src/mesa/libmesa.a $(TOP)/src/mapi/glapi/libglapi.a - - +CORE_MESA = \ + $(TOP)/src/mesa/libmesa.a \ + $(TOP)/src/mapi/glapi/libglapi.a \ + $(TOP)/src/glsl/cl/libglslcl.a \ + $(TOP)/src/glsl/pp/libglslpp.a .c.o: $(CC) -c $(INCLUDE_DIRS) $(CFLAGS) $ -o $@ signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] VTK Offscreen Segfaults
On 08/10/2010 04:44 PM, tom fogal wrote:
Kevin H. Hobbs hob...@ohiou.edu writes:
VTK_USE_X:BOOL=ON is set the test segfaults.
What does VTK_USE_X change/end up doing?
Most of the action seems to happen in Rendering/CMakeLists.txt where on
linux with VTK_USE_X=ON :
vtkXGPUInfoList.cxx is added to the list of sources.
vtkXRenderWindowInteractor.cxx is added to the list of sources.
cmake options for 3Dconnexion are exposed
vtkTestGLX.cmake is included
a try compile is made on CheckglXGetProcAddressARB.cxx
if OPENGL_gl_LIBRARY is also set
vtkXOpenGLRenderWindow.cxx is added to the list of sources.
and ${OPENGL_gl_LIBRARY} is added to the required libraries.
I'm leaving out stuff that seems to be for wrapping tcl and python.
a bunch of likely X11 directories are added to the search path.
cmake looks for X11 libraries
It seems like the test should only be calling OSMesa functions.
However, maybe the VTK_USE_X macro forces some always do this X init
kind of stuff, even when an X context isn't needed?
-tom
It's certainly possible. The test only does :
vtkRenderWindow *renWin = vtkRenderWindow::New();
renWin-OffScreenRenderingOn();
And I've always found that I have to do :
// Graphics Factory
vtkGraphicsFactory * graphics_factory
= vtkGraphicsFactory::New();
graphics_factory-SetOffScreenOnlyMode( 1);
graphics_factory-SetUseMesaClasses( 1 );
// Imaging Factory
vtkImagingFactory * imaging_factory
= vtkImagingFactory::New();
imaging_factory-SetUseMesaClasses( 1 );
// Render Window
vtkRenderWindow * render_window = vtkRenderWindow::New();
render_window-SetOffScreenRendering( 1 );
in order to get an offscreen program to run without DISPLAY set.
VTK does have another offscreen mode pbuffers or something that still
requires a display but can't be overwritten with another window.
Maybe this is what's being used in the VTK test.
However even if I add the factory lines to VTK's test the segfault
happens the same way.
signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] VTK Offscreen Segfaults
On 08/06/2010 05:20 PM, tom fogal wrote: Well, it does appear to be some type of symbol resolution/overloading issue. However it seems to be with internal Mesa symbols. Switching to a single library -- that is, putting OSMesaCreateContext, etc. into libGL directly, and getting rid of libOSMesa altogether -- seems like it would be the solution, but I imagine there's some reason that's not happening already. Let's ping Dan (added to the CC list), he knows more about this kind of thing than I do. Dan, have you been following this thread? The working theory is that there is a symbol in both libOSMesa and libGL. Something about the symbol existing in both is causing Badness during linking; seemingly innocuous changes cause Kevin's test program to jump into odd parts of Mesa (e.g. VBO code while doing initial matrix setup). The issue appears to be with internal symbols, but hidden symbol visibility isn't helping. I just did what might be an interesting experiment. I built mesa from HEAD with : ./autogen.sh --with-driver=xlib --disable-gallium --without-demos --enable-debug I set VTK_USE_X:BOOL=OFF OPENGL_gl_LIBRARY:FILEPATH=/home/kevin/mesa/lib/libGL.so OSMESA_LIBRARY:FILEPATH=/home/kevin/mesa/lib/libOSMesa.so in cmake and I still get the segfault but now I don't NEED libGL.so so when I replace libGL.so with libOSMesa.so : VTK_USE_X:BOOL=OFF OPENGL_gl_LIBRARY:FILEPATH=/home/kevin/mesa/lib/libOSMesa.so OSMESA_LIBRARY:FILEPATH=/home/kevin/mesa/lib/libOSMesa.so There is no more segfault and the test passes. signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] VTK Offscreen Segfaults
On 08/06/2010 05:20 PM, tom fogal wrote: Yeah... hrm, I thought Dan's change got rid of that, but maybe I misunderstood it. Could you rm /tmp/mesa/lib64/libGL.so* before building VTK? My hunch is that VTK is linking it in anyway; maybe it stuck around in cmake's cache or something. I added a line to my script to delete all of /tmp/mesa/lib64/libGL.so* after I build mesa and before I build VTK. I delete everything in the VTK build directory before the build. The test passed with mesa's libGL.* deleted. libOSMesa still tried to pull in libGL.so so it got nvidia's library. I took a look at src/mesa/drivers/osmesa/Makefile and it adds $(OSMESA_LIB_DEPS) to the build line. This is defined in configs/default as : OSMESA_LIB_DEPS = $(EXTRA_LIB_PATH) -L$(TOP)/$(LIB_DIR) -l$(GL_LIB) I removed the -l$(GL_LIB) from the end of this line and reran my script. The build failed with : Linking CXX executable ../../../bin/RenderingCxxTests ../../../bin/libvtkRendering.so.5.7.0: undefined reference to `glXMakeCurrent' ../../../bin/libvtkRendering.so.5.7.0: undefined reference to `glXGetConfig' ../../../bin/libvtkRendering.so.5.7.0: undefined reference to `glXGetCurrentDisplay' ../../../bin/libvtkRendering.so.5.7.0: undefined reference to `glXGetCurrentContext' ../../../bin/libvtkRendering.so.5.7.0: undefined reference to `glXQueryExtensionsString' ../../../bin/libvtkRendering.so.5.7.0: undefined reference to `glXQueryServerString' ../../../bin/libvtkRendering.so.5.7.0: undefined reference to `glXSwapBuffers' ../../../bin/libvtkRendering.so.5.7.0: undefined reference to `glXDestroyGLXPixmap' ../../../bin/libvtkRendering.so.5.7.0: undefined reference to `glXGetProcAddressARB' ../../../bin/libvtkRendering.so.5.7.0: undefined reference to `glXIsDirect' ../../../bin/libvtkRendering.so.5.7.0: undefined reference to `glXChooseVisual' ../../../bin/libvtkRendering.so.5.7.0: undefined reference to `glXCreateContext' ../../../bin/libvtkRendering.so.5.7.0: undefined reference to `glXDestroyContext' ../../../bin/libvtkRendering.so.5.7.0: undefined reference to `glXQueryExtension' ../../../bin/libvtkRendering.so.5.7.0: undefined reference to `glXGetClientString' collect2: ld returned 1 exit status make[3]: *** [bin/RenderingCxxTests] Error 1 make[2]: *** [Rendering/Testing/Cxx/CMakeFiles/RenderingCxxTests.dir/all] Error 2 make[1]: *** [Rendering/Testing/Cxx/CMakeFiles/RenderingCxxTests.dir/rule] Error 2 make: *** [RenderingCxxTests] Error 2 signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] VTK Offscreen Segfaults
On 08/05/2010 07:07 PM, tom fogal wrote: Brian Paul bri...@vmware.com writes: [snip] My other hunch is something is duplicated in the libOSMesa and libGL libraries that's causing things to blow up in general. Do note that both of these issues are from the pre--fvisibility=hidden by default days, which I was hoping/thinking would fix things... haven't looked into it though. It was also previous to Dan's recent 'change how libOSMesa is linked' fix (cbf30fce322506bd43692617de9d201533f41532)... but that commit is also required to fix a Mac linking issue, so I wouldn't advocate throwing it away for 7.8. Although I noticed the segfault with mesa configured and built with : ./autogen.sh \ --with-driver=xlib \ --disable-gallium \ --without-demos make -j 8 Because I have never been able to produce a working offscreen VTK with mesa configured this way, and since -fvisibility=hidden was added the ./autogen.sh way did not even build VTK untill the cbf30fce322506bd43692617de9d201533f41532 change. and that was about the same time that offscreen rendering stopped working for me no matter how I built mesa, my git bisect script uses : make -j8 linux-x86-64-debug so -fvisibility=hidden is not added to the command line of the builds in the git bisection. signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] VTK Offscreen Segfaults
On 08/05/2010 06:50 PM, Brian Paul wrote: Kevin, you seem to have identified two potential commits that caused trouble: 91c37599f621a0ec498c0f0add14f16470ca852b and 36b3a8bd5a317ab297f44b19fd14c7e76ec2fc77 You should go to the head of the Mesa git tree and then undo each of those changes one by one (either git-revert or patch -R, etc) and re-test to be absolutely sure that one or the other is causing the segfault. reverting 91c37 results in : Mesa: Mesa 7.9-devel DEBUG build Aug 6 2010 10:20:27 Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable Mesa: Initializing x86-64 optimizations RenderingCxxTests: main/renderbuffer.c:1902: _mesa_add_renderbuffer: Assertion `bufferName == BUFFER_DEPTH || bufferName == BUFFER_STENCIL || fb-Attachment[bufferName].Renderbuffer == ((void *)0)' failed. /home/kevin/kitware/os_bisect_script.sh: line 40: 14313 Aborted (core dumped) /tmp/VTK_Build/bin/RenderingCxxTests TestOSConeCxx -D /home/kevin/kitware/VTKData -T /tmp/VTK_Build/Testing/Temporary -V Baseline/Rendering/TestOSConeCxx.png I could not figure out how to revert ( without actually manually editing ) src/mesa/drivers/osmesa/osmesa.c so I reverted 36b3a 53a53 91c37 9b990 in reverse order as the were listed in : git log src/mesa/drivers/osmesa/osmesa.c The resulting build produced : Mesa: Mesa 7.9-devel DEBUG build Aug 6 2010 10:59:59 Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable Mesa: Initializing x86-64 optimizations Mesa: User error: GL_INVALID_ENUM in glGetTexGenfv(coord) /home/kevin/kitware/os_bisect_script.sh: line 40: 30622 Segmentation fault (core dumped) /tmp/VTK_Build/bin/RenderingCxxTests TestOSConeCxx -D /home/kevin/kitware/VTKData -T /tmp/VTK_Build/Testing/Temporary -V Baseline/Rendering/TestOSConeCxx.png Which looks a lot like the error I get with HEAD. The gdb session for this is : $ gdb /tmp/VTK_Build/bin/RenderingCxxTests GNU gdb (GDB) Fedora (7.1-24.fc13) Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-redhat-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /tmp/VTK_Build/bin/RenderingCxxTests...done. (gdb) run TestOSConeCxx \ -D /home/kevin/kitware/VTKData \ -T /tmp/VTK_Build/Testing/Temporary \ -V Baseline/Rendering/TestOSConeCxx.png Starting program: /tmp/VTK_Build/bin/RenderingCxxTests TestOSConeCxx -D /home/kevin/kitware/VTKData -T /tmp/VTK_Build/Testing/Temporary -V Baseline/Rendering/TestOSConeCxx.png [Thread debugging using libthread_db enabled] Mesa: Mesa 7.9-devel DEBUG build Aug 6 2010 10:59:59 Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable Mesa: Initializing x86-64 optimizations Mesa: User error: GL_INVALID_ENUM in glGetTexGenfv(coord) Program received signal SIGSEGV, Segmentation fault. 0x73c4ff79 in vbo_exec_EvalCoord1fv (u=0x203) at vbo/vbo_exec_api.c:458 458vbo_exec_EvalCoord1f( u[0] ); Missing separate debuginfos, use: debuginfo-install glibc-2.12-2.x86_64 libICE-1.0.6-2.fc13.x86_64 libSM-1.1.0-7.fc12.x86_64 libX11-1.3.1-3.fc13.x86_64 libXau-1.0.5-1.fc12.x86_64 libXext-1.1-2.fc13.x86_64 libXt-1.0.7-1.fc13.x86_64 libgcc-4.4.4-2.fc13.x86_64 libstdc++-4.4.4-2.fc13.x86_64 libuuid-2.17.2-5.fc13.x86_64 libxcb-1.5-1.fc13.x86_64 (gdb) bt #0 0x73c4ff79 in vbo_exec_EvalCoord1fv (u=0x203) at vbo/vbo_exec_api.c:458 #1 0x73c3ddc3 in neutral_EvalCoord1fv (v=0x203) at main/vtxfmt_tmp.h:79 #2 0x77b2f735 in vtkOpenGLRenderWindow::OpenGLInit (this=0x69d770) at /tmp/VTK/Rendering/vtkOpenGLRenderWindow.cxx:241 #3 0x77b8ab02 in vtkXOpenGLRenderWindow::CreateOffScreenWindow (this=0x69d770, width=300, height=300) at /tmp/VTK/Rendering/vtkXOpenGLRenderWindow.cxx:951 #4 0x77b8af81 in vtkXOpenGLRenderWindow::Initialize (this=0x69d770) at /tmp/VTK/Rendering/vtkXOpenGLRenderWindow.cxx:1066 #5 0x77b8b387 in vtkXOpenGLRenderWindow::Start (this=0x69d770) at /tmp/VTK/Rendering/vtkXOpenGLRenderWindow.cxx:1185 #6 0x77a51c51 in vtkRenderWindow::DoStereoRender (this=0x69d770) at /tmp/VTK/Rendering/vtkRenderWindow.cxx:687 #7 0x77a51c22 in vtkRenderWindow::DoFDRender (this=0x69d770) at /tmp/VTK/Rendering/vtkRenderWindow.cxx:676 #8 0x77a51622 in vtkRenderWindow::DoAARender (this=0x69d770) at /tmp/VTK/Rendering/vtkRenderWindow.cxx:563 #9 0x77a50a32 in vtkRenderWindow::Render (this=0x69d770) at /tmp/VTK/Rendering/vtkRenderWindow.cxx:376 #10 0x77b8dde7 in vtkXOpenGLRenderWindow::Render (this=0x69d770) at /tmp/VTK/Rendering/vtkXOpenGLRenderWindow.cxx:1845
Re: [Mesa-dev] VTK Offscreen Segfaults
On 08/06/2010 10:47 AM, tom fogal wrote: Kevin H. Hobbs hob...@ohiou.edu writes: my git bisect script uses : make -j8 linux-x86-64-debug so -fvisibility=3Dhidden is not added to the command line of the builds in the git bisection. Oh. Can you add it into your bisect script and try again? sed -i s,OPT_FLAGS = -g,OPT_FLAGS=-g -fvisibility=hidden, linux-x86-64-debug Should do it. -tom I added this to my bisect script and did : git clone git://anongit.freedesktop.org/git/mesa/mesa cd mesa git bisect start git bisect bad git bisect good cbf30fce322506bd43692617de9d201533f41532 # anything before this won't build with -fvisibility=hidden What I got was : 91c37599f621a0ec498c0f0add14f16470ca852b is the first bad commit commit 91c37599f621a0ec498c0f0add14f16470ca852b Author: Brian Paul bri...@vmware.com Date: Fri Jul 2 18:18:15 2010 -0600 osmesa: remove old renderbuffer before adding new Fixes fd.o bug 10966 when OSMesaMakeCurrent() was called twice. NOTE: This is a candidate for the 7.8 branch. :04 04 a4ba3e3942358d9f65e1776be65f6c777e2e9727 fc9d13a49f9091236be27945a3aafbcf347ea55f M src bisect run success which is the same as before. signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] VTK Offscreen Segfaults
On 08/04/2010 03:01 PM, tom fogal wrote: No --enable-gl-osmesa ? That's right I do not have --enable-gl-osmesa. according to configure --help this is on by default when the xlib driver is used. 1) Make sure you've got -fvisibility=hidden when you're building; the VBO code seems to exist in multiple s.o. and i've seen similar segfaults before w.r.t. jumping into the wrong shared object (since Mesa has two libs that VTK needs). -fvisibility=hidden appears on almost every line of the make output. 2) Make sure to switch the Mesa libraries in VTK's CMake step. The critical component is that your link lines must put OSMesa and MesaGL in the 'correct' ordering, where 'correct' depends on which you want to use (sounds like OSMesa in your case, so OSMesa should come first). This VTK dashboard build has : OPENGL_INCLUDE_DIR:PATH=/home/kevin/mesa/include/ OPENGL_gl_LIBRARY:FILEPATH=/home/kevin/mesa/lib/libGL.so OPENGL_glu_LIBRARY:FILEPATH=/home/kevin/mesa/lib/libGLU.so OPENGL_xmesa_INCLUDE_DIR:PATH=/home/kevin/mesa/include/ VTK_OPENGL_HAS_OSMESA:BOOL=ON OSMESA_INCLUDE_DIR:PATH=/home/kevin/mesa/include/ OSMESA_LIBRARY:FILEPATH=/home/kevin/mesa/lib/libOSMesa.so If anything else is required to get passing tests then I'll file a bug against VTK. 3) Doesn't seem likely that ::OpenGLInit calls vbo_exec_EvalCoord1fv :) Are you missing debug symbols in Mesa? Could you get a stack trace w/ full debug symbols? Ag now I see --enable-debug in mesa's ./configure --help output. I'll rebuild everything and get a new backtrace. signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] VTK Offscreen Segfaults
On 08/04/2010 03:01 PM, tom fogal wrote: 3) Doesn't seem likely that ::OpenGLInit calls vbo_exec_EvalCoord1fv :) Are you missing debug symbols in Mesa? Could you get a stack trace w/ full debug symbols? The full gdb session with both mesa and VTK built with debug symbols is : $ gdb /home/kevin/kitware/VTK_Build/bin/RenderingCxxTests GNU gdb (GDB) Fedora (7.1-24.fc13) Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-redhat-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /home/kevin/kitware/VTK_Build/bin/RenderingCxxTests...done. (gdb) run TestOSConeCxx -D /home/kevin/kitware/VTKData -T /home/kevin/kitware/VTK_Build/Testing/Temporary -V Baseline/Rendering/TestOSConeCxx.png Starting program: /home/kevin/kitware/VTK_Build/bin/RenderingCxxTests TestOSConeCxx -D /home/kevin/kitware/VTKData -T /home/kevin/kitware/VTK_Build/Testing/Temporary -V Baseline/Rendering/TestOSConeCxx.png [Thread debugging using libthread_db enabled] Mesa: Mesa 7.9-devel DEBUG build Aug 4 2010 15:25:34 Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable Mesa: Initializing x86-64 optimizations Mesa: User error: GL_INVALID_ENUM in glGetTexGenfv(coord) Program received signal SIGSEGV, Segmentation fault. vbo_exec_EvalCoord1fv (u=0x203) at vbo/vbo_exec_api.c:458 458vbo_exec_EvalCoord1f( u[0] ); Missing separate debuginfos, use: debuginfo-install expat-2.0.1-10.fc13.x86_64 fontconfig-2.8.0-1.fc13.x86_64 freetype-2.3.11-3.fc13.x86_64 glibc-2.12-2.x86_64 libICE-1.0.6-2.fc13.x86_64 libSM-1.1.0-7.fc12.x86_64 libX11-1.3.1-3.fc13.x86_64 libXScrnSaver-1.2.0-1.fc12.x86_64 libXau-1.0.5-1.fc12.x86_64 libXext-1.1-2.fc13.x86_64 libXft-2.1.14-1.fc13.x86_64 libXrender-0.9.5-1.fc13.x86_64 libXt-1.0.7-1.fc13.x86_64 libgcc-4.4.4-2.fc13.x86_64 libstdc++-4.4.4-2.fc13.x86_64 libuuid-2.17.2-5.fc13.x86_64 libxcb-1.5-1.fc13.x86_64 (gdb) bt #0 vbo_exec_EvalCoord1fv (u=0x203) at vbo/vbo_exec_api.c:458 #1 0x77b3263d in vtkOpenGLRenderWindow::OpenGLInit (this=0x69d310) at /home/kevin/kitware/VTK/Rendering/vtkOpenGLRenderWindow.cxx:241 #2 0x77b8c45e in vtkXOpenGLRenderWindow::CreateOffScreenWindow (this=0x69d310, width=300, height=300) at /home/kevin/kitware/VTK/Rendering/vtkXOpenGLRenderWindow.cxx:951 #3 0x77b8c8dd in vtkXOpenGLRenderWindow::Initialize (this=0x69d310) at /home/kevin/kitware/VTK/Rendering/vtkXOpenGLRenderWindow.cxx:1066 #4 0x77b8cce3 in vtkXOpenGLRenderWindow::Start (this=0x69d310) at /home/kevin/kitware/VTK/Rendering/vtkXOpenGLRenderWindow.cxx:1185 #5 0x77a54fc1 in vtkRenderWindow::DoStereoRender (this=0x69d310) at /home/kevin/kitware/VTK/Rendering/vtkRenderWindow.cxx:687 #6 0x77a54f92 in vtkRenderWindow::DoFDRender (this=0x69d310) at /home/kevin/kitware/VTK/Rendering/vtkRenderWindow.cxx:676 #7 0x77a54992 in vtkRenderWindow::DoAARender (this=0x69d310) at /home/kevin/kitware/VTK/Rendering/vtkRenderWindow.cxx:563 #8 0x77a53da2 in vtkRenderWindow::Render (this=0x69d310) at /home/kevin/kitware/VTK/Rendering/vtkRenderWindow.cxx:376 #9 0x77b8f743 in vtkXOpenGLRenderWindow::Render (this=0x69d310) at /home/kevin/kitware/VTK/Rendering/vtkXOpenGLRenderWindow.cxx:1845 #10 0x00432696 in TestOSConeCxx (argc=7, argv=0x7fffd960) at /home/kevin/kitware/VTK/Rendering/Testing/Cxx/TestOSConeCxx.cxx:68 #11 0x0041b683 in main (ac=7, av=0x7fffd960) at /home/kevin/kitware/VTK_Build/Rendering/Testing/Cxx/RenderingCxxTests.cxx:454 signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] VTK Offscreen Segfaults
On 08/04/2010 04:21 PM, tom fogal wrote: I am not sure what is wrong here, but something is. vbo_exec_EvalCoord1fv and vbo_exec_EvalCoord1f are both static methods in that file... there is no way OpenGLInit could call them. They must be called automagically during OSMesaCreateContext or similar, but we should *see* the CreateContext call somewhere in the backtrace and I am not sure why we do not. Can you try valgrind? Perhaps somehow the generated dispatch code is jumping into lalaland and somehow magically ends up in vbo_exec_EvalCoord1fv (pretty far-fetched, but I'm out of ideas here...). The output from valgrind is : $ valgrind --trace-children=yes /home/kevin/kitware/VTK_Build/bin/RenderingCxxTests TestOSConeCxx -D /home/kevin/kitware/VTKData -T /home/kevin/kitware/VTK_Build/Testing/Temporary -V Baseline/Rendering/TestOSConeCxx.png ==5115== Memcheck, a memory error detector ==5115== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==5115== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==5115== Command: /home/kevin/kitware/VTK_Build/bin/RenderingCxxTests TestOSConeCxx -D /home/kevin/kitware/VTKData -T /home/kevin/kitware/VTK_Build/Testing/Temporary -V Baseline/Rendering/TestOSConeCxx.png ==5115== Mesa: Mesa 7.9-devel DEBUG build Aug 4 2010 15:25:34 Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable Mesa: Initializing x86-64 optimizations Mesa: User error: GL_INVALID_VALUE in glPixelMapusv(mapsize) ==5115== Invalid read of size 1 ==5115==at 0x4A06A68: memcpy (mc_replace_strmem.c:497) ==5115==by 0x8A7F05F: _mesa_unpack_bitmap (image.c:1215) ==5115==by 0x8A7F0E8: _mesa_unpack_polygon_stipple (image.c:1140) ==5115==by 0x8A8B7D4: _mesa_polygon_stipple (polygon.c:202) ==5115==by 0x8A8BEAA: _mesa_PolygonStipple (polygon.c:222) ==5115==by 0x5033646: vtkOpenGLRenderWindow::OpenGLInit() (vtkOpenGLRenderWindow.cxx:242) ==5115==by 0x508D45D: vtkXOpenGLRenderWindow::CreateOffScreenWindow(int, int) (vtkXOpenGLRenderWindow.cxx:951) ==5115==by 0x508D8DC: vtkXOpenGLRenderWindow::Initialize() (vtkXOpenGLRenderWindow.cxx:1066) ==5115==by 0x508DCE2: vtkXOpenGLRenderWindow::Start() (vtkXOpenGLRenderWindow.cxx:1185) ==5115==by 0x4F55FC0: vtkRenderWindow::DoStereoRender() (vtkRenderWindow.cxx:687) ==5115==by 0x4F55F91: vtkRenderWindow::DoFDRender() (vtkRenderWindow.cxx:676) ==5115==by 0x4F55991: vtkRenderWindow::DoAARender() (vtkRenderWindow.cxx:563) ==5115== Address 0xb74 is not stack'd, malloc'd or (recently) free'd ==5115== ==5115== ==5115== Process terminating with default action of signal 11 (SIGSEGV) ==5115== Access not within mapped region at address 0xB74 ==5115==at 0x4A06A68: memcpy (mc_replace_strmem.c:497) ==5115==by 0x8A7F05F: _mesa_unpack_bitmap (image.c:1215) ==5115==by 0x8A7F0E8: _mesa_unpack_polygon_stipple (image.c:1140) ==5115==by 0x8A8B7D4: _mesa_polygon_stipple (polygon.c:202) ==5115==by 0x8A8BEAA: _mesa_PolygonStipple (polygon.c:222) ==5115==by 0x5033646: vtkOpenGLRenderWindow::OpenGLInit() (vtkOpenGLRenderWindow.cxx:242) ==5115==by 0x508D45D: vtkXOpenGLRenderWindow::CreateOffScreenWindow(int, int) (vtkXOpenGLRenderWindow.cxx:951) ==5115==by 0x508D8DC: vtkXOpenGLRenderWindow::Initialize() (vtkXOpenGLRenderWindow.cxx:1066) ==5115==by 0x508DCE2: vtkXOpenGLRenderWindow::Start() (vtkXOpenGLRenderWindow.cxx:1185) ==5115==by 0x4F55FC0: vtkRenderWindow::DoStereoRender() (vtkRenderWindow.cxx:687) ==5115==by 0x4F55F91: vtkRenderWindow::DoFDRender() (vtkRenderWindow.cxx:676) ==5115==by 0x4F55991: vtkRenderWindow::DoAARender() (vtkRenderWindow.cxx:563) ==5115== If you believe this happened as a result of a stack ==5115== overflow in your program's main thread (unlikely but ==5115== possible), you can try to increase the size of the ==5115== main thread stack using the --main-stacksize= flag. ==5115== The main thread stack size used in this run was 10485760. ==5115== Invalid free() / delete / delete[] ==5115==at 0x4A04D72: free (vg_replace_malloc.c:325) ==5115==by 0x3E5052CAAA: ??? (in /lib64/libc-2.12.so) ==5115==by 0x3E5052C641: ??? (in /lib64/libc-2.12.so) ==5115==by 0x480162B: _vgnU_freeres (vg_preloaded.c:62) ==5115==by 0xA6DD2CF: ??? ==5115==by 0x8A7F05F: _mesa_unpack_bitmap (image.c:1215) ==5115==by 0x8A7F0E8: _mesa_unpack_polygon_stipple (image.c:1140) ==5115==by 0x8A8B7D4: _mesa_polygon_stipple (polygon.c:202) ==5115==by 0x8A8BEAA: _mesa_PolygonStipple (polygon.c:222) ==5115==by 0x5033646: vtkOpenGLRenderWindow::OpenGLInit() (vtkOpenGLRenderWindow.cxx:242) ==5115==by 0x508D45D: vtkXOpenGLRenderWindow::CreateOffScreenWindow(int, int) (vtkXOpenGLRenderWindow.cxx:951) ==5115==by 0x508D8DC: vtkXOpenGLRenderWindow::Initialize() (vtkXOpenGLRenderWindow.cxx:1066) ==5115== Address 0x854f390 is not stack'd, malloc'd or (recently) free'd ==5115== ==5115== ==5115==
Re: [Mesa-dev] VTK Offscreen Segfaults
On 08/04/2010 04:21 PM, tom fogal wrote: Can you try valgrind? Perhaps somehow the generated dispatch code is jumping into lalaland and somehow magically ends up in vbo_exec_EvalCoord1fv (pretty far-fetched, but I'm out of ideas here...). valgrind suggested I add --leak-check=full which certainly added some information : $ valgrind --trace-children=yes --leak-check=full /home/kevin/kitware/VTK_Build/bin/RenderingCxxTests TestOSConeCxx -D /home/kevin/kitware/VTKData -T /home/kevin/kitware/VTK_Build/Testing/Temporary -V Baseline/Rendering/TestOSConeCxx.png ==5240== Memcheck, a memory error detector ==5240== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==5240== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==5240== Command: /home/kevin/kitware/VTK_Build/bin/RenderingCxxTests TestOSConeCxx -D /home/kevin/kitware/VTKData -T /home/kevin/kitware/VTK_Build/Testing/Temporary -V Baseline/Rendering/TestOSConeCxx.png ==5240== Mesa: Mesa 7.9-devel DEBUG build Aug 4 2010 15:25:34 Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable Mesa: Initializing x86-64 optimizations Mesa: User error: GL_INVALID_VALUE in glPixelMapusv(mapsize) ==5240== Invalid read of size 1 ==5240==at 0x4A06A68: memcpy (mc_replace_strmem.c:497) ==5240==by 0x8A7F05F: _mesa_unpack_bitmap (image.c:1215) ==5240==by 0x8A7F0E8: _mesa_unpack_polygon_stipple (image.c:1140) ==5240==by 0x8A8B7D4: _mesa_polygon_stipple (polygon.c:202) ==5240==by 0x8A8BEAA: _mesa_PolygonStipple (polygon.c:222) ==5240==by 0x5033646: vtkOpenGLRenderWindow::OpenGLInit() (vtkOpenGLRenderWindow.cxx:242) ==5240==by 0x508D45D: vtkXOpenGLRenderWindow::CreateOffScreenWindow(int, int) (vtkXOpenGLRenderWindow.cxx:951) ==5240==by 0x508D8DC: vtkXOpenGLRenderWindow::Initialize() (vtkXOpenGLRenderWindow.cxx:1066) ==5240==by 0x508DCE2: vtkXOpenGLRenderWindow::Start() (vtkXOpenGLRenderWindow.cxx:1185) ==5240==by 0x4F55FC0: vtkRenderWindow::DoStereoRender() (vtkRenderWindow.cxx:687) ==5240==by 0x4F55F91: vtkRenderWindow::DoFDRender() (vtkRenderWindow.cxx:676) ==5240==by 0x4F55991: vtkRenderWindow::DoAARender() (vtkRenderWindow.cxx:563) ==5240== Address 0xb74 is not stack'd, malloc'd or (recently) free'd ==5240== ==5240== ==5240== Process terminating with default action of signal 11 (SIGSEGV) ==5240== Access not within mapped region at address 0xB74 ==5240==at 0x4A06A68: memcpy (mc_replace_strmem.c:497) ==5240==by 0x8A7F05F: _mesa_unpack_bitmap (image.c:1215) ==5240==by 0x8A7F0E8: _mesa_unpack_polygon_stipple (image.c:1140) ==5240==by 0x8A8B7D4: _mesa_polygon_stipple (polygon.c:202) ==5240==by 0x8A8BEAA: _mesa_PolygonStipple (polygon.c:222) ==5240==by 0x5033646: vtkOpenGLRenderWindow::OpenGLInit() (vtkOpenGLRenderWindow.cxx:242) ==5240==by 0x508D45D: vtkXOpenGLRenderWindow::CreateOffScreenWindow(int, int) (vtkXOpenGLRenderWindow.cxx:951) ==5240==by 0x508D8DC: vtkXOpenGLRenderWindow::Initialize() (vtkXOpenGLRenderWindow.cxx:1066) ==5240==by 0x508DCE2: vtkXOpenGLRenderWindow::Start() (vtkXOpenGLRenderWindow.cxx:1185) ==5240==by 0x4F55FC0: vtkRenderWindow::DoStereoRender() (vtkRenderWindow.cxx:687) ==5240==by 0x4F55F91: vtkRenderWindow::DoFDRender() (vtkRenderWindow.cxx:676) ==5240==by 0x4F55991: vtkRenderWindow::DoAARender() (vtkRenderWindow.cxx:563) ==5240== If you believe this happened as a result of a stack ==5240== overflow in your program's main thread (unlikely but ==5240== possible), you can try to increase the size of the ==5240== main thread stack using the --main-stacksize= flag. ==5240== The main thread stack size used in this run was 10485760. ==5240== Invalid free() / delete / delete[] ==5240==at 0x4A04D72: free (vg_replace_malloc.c:325) ==5240==by 0x3E5052CAAA: ??? (in /lib64/libc-2.12.so) ==5240==by 0x3E5052C641: ??? (in /lib64/libc-2.12.so) ==5240==by 0x480162B: _vgnU_freeres (vg_preloaded.c:62) ==5240==by 0xA6DD2CF: ??? ==5240==by 0x8A7F05F: _mesa_unpack_bitmap (image.c:1215) ==5240==by 0x8A7F0E8: _mesa_unpack_polygon_stipple (image.c:1140) ==5240==by 0x8A8B7D4: _mesa_polygon_stipple (polygon.c:202) ==5240==by 0x8A8BEAA: _mesa_PolygonStipple (polygon.c:222) ==5240==by 0x5033646: vtkOpenGLRenderWindow::OpenGLInit() (vtkOpenGLRenderWindow.cxx:242) ==5240==by 0x508D45D: vtkXOpenGLRenderWindow::CreateOffScreenWindow(int, int) (vtkXOpenGLRenderWindow.cxx:951) ==5240==by 0x508D8DC: vtkXOpenGLRenderWindow::Initialize() (vtkXOpenGLRenderWindow.cxx:1066) ==5240== Address 0x854f390 is not stack'd, malloc'd or (recently) free'd ==5240== ==5240== ==5240== HEAP SUMMARY: ==5240== in use at exit: 8,928,115 bytes in 2,120 blocks ==5240== total heap usage: 2,778 allocs, 659 frees, 9,011,811 bytes allocated ==5240== ==5240== 192 bytes in 1 blocks are definitely lost in loss record 1,209 of 1,363 ==5240==at 0x4A04481: calloc
Re: [Mesa-dev] Build failure since May 6
On 05/14/2010 08:51 AM, Dan Nicholson wrote: On Thu, May 13, 2010 at 7:40 AM, Kevin H. Hobbs hob...@ohiou.edu wrote: I tried it and it tests as well with VTK as any recent build. Thanks. Well, you and Tom use a standalone osmesa. The only distro I looked at (fedora) uses a standalone osmesa. Maybe the build should just do that instead of trying to link to gl in some situations. It could certainly make the build a lot nicer. I'll try to put that into a formal patch since there's some other cleanup. -- Dan I look forward to the patch. I am confused about the term standalone osmesa could you please tell me if you mean : 1. a build of Mesa where only libOSMesa.so is produced? 2. a build of Mesa where libGL.so and libOSMesa.so are produced but the dynamic linker will need no symbols from libGL.so in order to load libOSMesa.so? 3. a build of Mesa where libGL.so and libOSMesa.so are produced but the dynamic linker will need symbols from libGL.so in order to load libOSMesa.so. I have been using the build target : make linux-x86-64 to test VTK and ParaView. I believe this build target is the case 3 above which sounds to me like standalone Mesa but not really standalone OSMesa which could be cases 1 and 2 above. The build target created by configure --with-driver=xlib also seems to be case 3 above but because of the hidden symbols problem from -fvisibility=hidden your patch will make this target produce case 2 above. Is all that correct? signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Build failure since May 6
On 05/14/2010 10:58 AM, Brian Paul wrote: Kevin H. Hobbs wrote: 1. a build of Mesa where only libOSMesa.so is produced? 2. a build of Mesa where libGL.so and libOSMesa.so are produced but the dynamic linker will need no symbols from libGL.so in order to load libOSMesa.so? 3. a build of Mesa where libGL.so and libOSMesa.so are produced but the dynamic linker will need symbols from libGL.so in order to load libOSMesa.so. I don't think many people still make use of that feature. I think it's more common to build Mesa with name mangling to do OSMesa rendering with the mgl* functions and hardware rendering through the gl* functions (with any vendor's libGL). The advice I got from the ParaView developers (I think it was Berk Geveci) was to skip name mangling of Mesa and build the PV client with vendor libGL.so and build the PV server with Mesa/OSMesa. This is for the situation where you have many server processes on hosts without monitors, graphics hardware, or an Xserver, and a client with all of those things. signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Build failure since May 6
On 05/10/2010 04:48 PM, Dan Nicholson wrote: On Mon, May 10, 2010 at 12:51 PM, Kevin H. Hobbs hob...@ohiou.edu wrote: The mesa/configs/linux-x86-64 target makes this symbol global while the auto tools configuration makes this symbol local... I guess this is because configure adds -fvisibility=hidden to the CFLAGS. Maybe we should always build osmesa against the internal static libraries instead of against libGL. -- Dan I am always available ( well today I'll be doing a dissection so I won't be so available) to try patches, workarounds,and hacks. signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Build failure since May 6
On 05/10/2010 09:46 AM, Brian Paul wrote: A 'make clean' may be needed. Sometimes when source files move around the 'depend' files don't get properly updated. -Brian I get the same result after 'make clean' err.. at least the build fails with : make[5]: *** No rule to make target `../../../../src/mapi/glapi/libglapi.a', needed by `../../../../lib64/libGL.so'. Stop. I suppose I should mention that this is Fedora 12 x86_64 so: $ rpm -q gcc imake gcc-4.4.3-4.fc12.x86_64 imake-1.0.2-12.fc12.x86_64 I deleted my mesa directory and re-cloned the repository and tried to build but the build stopped here : gcc -c -I. -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers -Wall -Wmissing-prototypes -Wdeclaration-after-statement -Wpointer-arith -O3 -g -fPIC -m64 -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DPTHREADS -DUSE_XSHM -DHAVE_POSIX_MEMALIGN -DUSE_X86_64_ASM -I/usr/X11R6/include -std=c99 -ffast-math -fno-strict-aliasing nv50_clear.c -o nv50_clear.o In file included from nv50_context.h:19, from nv50_clear.c:28: ../../../../src/gallium/drivers/nouveau/nouveau_stateobj.h: In function ‘so_emit’: ../../../../src/gallium/drivers/nouveau/nouveau_stateobj.h:262: error: ‘struct nouveau_channel’ has no member named ‘cur’ signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Build failure since May 6
On 05/10/2010 11:56 AM, tom fogal wrote: I recommend you check out the build_mesa function in: http://portal.nersc.gov/svn/visit/trunk/src/svn_bin/build_visit There's a lot we can do to make the whole VTK, Mesa/mangled or no, and VisIt/ParaView stack more amenable to compilation / easier to get going. Let me know if you are interested in dividing up some of that work. Cheers, -tom The builds I submit to the VTK and ParaView dashboards all use Mesa and OSMesa without direct rendering as the only GL. These builds all use the make files included with Mesa and not the autoconf method. Mesa is built with make linux-x86-64 This is the only way I've ever found to get VTK and ParaView working on and off screen. I've never had Mangled Mesa work with VTK. Nor have I had Mesa built with the configure scripts work on and off screen with VTK. I even remember some mess in a .spec file where mesa was built with DRI installed and then OSMesa was built and installed. That didn't work either. If there's another way I'd love to hear it, and I'll do whatever I can to help. I'm sure I don't fully understand the build_mesa function in the build_visit script but it seems like it's doing name mangling and such to support accelerated onscreen and mesa offscreen rendering in a single VTK build. All I really want is Mesa with OSMesa from the development repository as the reference library for my VTK and ParaView nightly test builds. signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Build failure since May 6
On 05/10/2010 02:13 PM, Dan Nicholson wrote: On Mon, May 10, 2010 at 10:08 AM, Kevin H. Hobbs hob...@ohiou.edu wrote: All I really want is Mesa with OSMesa from the development repository as the reference library for my VTK and ParaView nightly test builds. ./configure --with-driver=xlib ? That will link libOSMesa to libGL, but that's what configs/linux-x86-64 is already doing (I think). If that's not working for you, please let me know. I tried to make this work correctly in the past, but personally use the dri drivers. -- Dan I just built mesa with : make clean git pull origin ./autogen.sh --with-driver=xlib gmake And I agree from the output from --help this should be the same as make linux-x86-64. I tried a VTK test build against this mesa and I got this : http://www.cdash.org/CDash/viewBuildError.php?buildid=606216 /home/kevin/mesa/lib/libOSMesa.so.7: undefined reference to `_mesa_create_framebuffer' This VTK is built with : OPENGL_INCLUDE_DIR:PATH=/home/kevin/mesa/include/ OPENGL_gl_LIBRARY:FILEPATH=/home/kevin/mesa/lib/libGL.so OPENGL_glu_LIBRARY:FILEPATH=/home/kevin/mesa/lib/libGLU.so OPENGL_xmesa_INCLUDE_DIR:PATH=/home/kevin/mesa/include/ VTK_OPENGL_HAS_OSMESA:BOOL=ON OSMESA_INCLUDE_DIR:PATH=/home/kevin/mesa/include/ OSMESA_LIBRARY:FILEPATH=/home/kevin/mesa/lib/libOSMesa.so I really do not understand this missing symbol business since : $ nm mesa/lib/libOSMesa.so | grep _mesa_free_context_data U _mesa_free_context_data $ nm mesa/lib/libGL.so | grep _mesa_free_context_data 00078030 t _mesa_free_context_data $ nm /opt/Mesa-7.8.1/lib64/libOSMesa.so | grep _mesa_free_context_data U _mesa_free_context_data $ nm /opt/Mesa-7.8.1/lib64/libGL.so | grep _mesa_free_context_data 00092bc0 T _mesa_free_context_data The symbol is defined in the same library in mesa built from the git repo with autogen.sh --with-driver=xlib and in mesa built from the release tarball with make linux-x86-64. One VTK fails to build one VTK passes most tests : http://www.cdash.org/CDash/buildSummary.php?buildid=606219 signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Build failure since May 6
On 05/10/2010 03:25 PM, Kevin H. Hobbs wrote: I really do not understand this missing symbol business since : $ nm mesa/lib/libGL.so | grep _mesa_free_context_data 00078030 t _mesa_free_context_data $ nm /opt/Mesa-7.8.1/lib64/libGL.so | grep _mesa_free_context_data 00092bc0 T _mesa_free_context_data Well there is a difference! Uppercase is global lower case is local. The mesa/configs/linux-x86-64 target makes this symbol global while the auto tools configuration makes this symbol local... signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
