bugle-devel Mailing List for BuGLe (Page 4)
Status: Inactive
Brought to you by:
bmerry
Menu
▾
▴
bugle-devel — For people hacking on bugle
You can subscribe to this list here.
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(6) |
Nov
(6) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2010 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(2) |
Jun
(2) |
Jul
(12) |
Aug
(7) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2011 |
Jan
|
Feb
(2) |
Mar
|
Apr
(2) |
May
(2) |
Jun
|
Jul
|
Aug
(5) |
Sep
|
Oct
(4) |
Nov
(12) |
Dec
(3) |
| 2012 |
Jan
(6) |
Feb
|
Mar
(23) |
Apr
|
May
(9) |
Jun
(3) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(5) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
(5) |
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: bugle - T. i. <no...@so...> - 2011-10-22 20:45:49
|
#91: Using bugle causes fallback to indirect rendering with NVIDIA on Ubuntu
-------------------------+--------------------------------------------------
Reporter: bmerry | Owner: bmerry
Type: defect | Status: new
Priority: major | Component: core
Version: 0.0.20101121 | Keywords:
-------------------------+--------------------------------------------------
This was discussed recently on the mailing list. The cause is that BuGLe
dynamically loads "libGL.so", which does not match the usual SONAME of
"libGL.so.1". Normally they're the same, but in this case it causes Mesa
to be loaded instead of the proprietary driver.
It's not completely trivial to fix, due to the cross-product of GL
flavors, window system interface flavours (EGL vs WGL/GLX), and operating
system DLL extensions (.dll vs .so).
--
Ticket URL: <http://sourceforge.net/apps/trac/bugle/ticket/91>
BuGLe <http://www.opengl.org/sdk/tools/BuGLe>
An open-source OpenGL debugger
|
|
From: bugle - T. i. <no...@so...> - 2011-08-24 20:51:26
|
#90: gengl for GLX should consider None as a token
-------------------------+--------------------------------------------------
Reporter: bmerry | Owner: bmerry
Type: defect | Status: new
Priority: major | Component: core
Version: 0.0.20101121 | Keywords:
-------------------------+--------------------------------------------------
Currently when dumping an attribute list, the terminator is being written
as whatever gengl found lying around that happened to by #defined to 0,
instead of the symbolic name `None`. This symbol is defined by X rather
than GLX, so it should probably just be injected manually in gengl.
Now if only I hadn't written gengl in a write-only language...
--
Ticket URL: <http://sourceforge.net/apps/trac/bugle/ticket/90>
BuGLe <http://www.opengl.org/sdk/tools/BuGLe>
An open-source OpenGL debugger
|
|
From: bugle - T. i. <no...@so...> - 2011-08-24 19:39:06
|
#87: exe filter-set does not support glMapBuffer
-------------------------+--------------------------------------------------
Reporter: bmerry | Owner: bmerry
Type: defect | Status: new
Priority: minor | Component: filter-sets
Version: 0.0.20101121 | Keywords:
-------------------------+--------------------------------------------------
--
Ticket URL: <http://sourceforge.net/apps/trac/bugle/ticket/87#comment:1>
BuGLe <http://www.opengl.org/sdk/tools/BuGLe>
An open-source OpenGL debugger
|
|
From: bugle - T. i. <no...@so...> - 2011-08-24 19:39:05
|
#89: Support test-only filter sets in test framework
-------------------------+--------------------------------------------------
Reporter: bmerry | Owner: bmerry
Type: enhancement | Status: new
Priority: enhancement | Component: tests
Version: 0.0.20101121 | Keywords:
-------------------------+--------------------------------------------------
Some functionality is made available from the core to filter-sets, and
this is the interface boundary at which it is most appropriate to test it
(the current place I'm hitting this limitation is in testing the ability
to produce aux contexts in combination with GLX_ARB_create_context). It
should be possible to specify in the test script a filter set file that
will be built and used for the test, but not shipped.
--
Ticket URL: <http://sourceforge.net/apps/trac/bugle/ticket/89>
BuGLe <http://www.opengl.org/sdk/tools/BuGLe>
An open-source OpenGL debugger
|
|
From: bugle - T. i. <no...@so...> - 2011-08-24 19:23:02
|
#88: Enhance typing system to deal with heterogeneous lists
------------------------+---------------------------------------------------
Reporter: bmerry | Owner: bmerry
Type: enhancement | Status: new
Priority: enhancement | Component: core
Version: SVN | Keywords:
------------------------+---------------------------------------------------
The current .bc files cannot describe a pointer to a list of elements of
different semantic types. Currently this is handled by overriding the
dumping function to customize the display of the elements, and even then
it has limited success. A fully general replacement would allow a function
to accept a marshalled call object and produce a tree of information. Each
leaf in the tree could include raw value, semantic type and dumped string
value.
--
Ticket URL: <http://sourceforge.net/apps/trac/bugle/ticket/88>
BuGLe <http://www.opengl.org/sdk/tools/BuGLe>
An open-source OpenGL debugger
|
|
From: bugle - T. i. <no...@so...> - 2011-08-24 19:19:19
|
#87: exe filter-set does not support `glMapBuffer`
-------------------------+--------------------------------------------------
Reporter: bmerry | Owner: bmerry
Type: defect | Status: new
Priority: minor | Component: filter-sets
Version: 0.0.20101121 | Keywords:
-------------------------+--------------------------------------------------
When a buffer is mapped for writing, we need to trap the matching
`glUnmapBuffer` and read back the buffer contents. Similarly for
`glMapBufferRange`.
--
Ticket URL: <http://sourceforge.net/apps/trac/bugle/ticket/87>
BuGLe <http://www.opengl.org/sdk/tools/BuGLe>
An open-source OpenGL debugger
|
|
From: bugle - T. i. <no...@so...> - 2011-05-11 11:13:15
|
#86: Seg fault in gldb-gui-buffer.c when compiling under msvc
-------------------------+--------------------------------------------------
Reporter: singing-tree | Owner: bmerry
Type: defect | Status: new
Priority: minor | Component: Windows port
Version: 0.0.20101121 | Keywords:
-------------------------+--------------------------------------------------
Line 472 of gldb-gui-buffer.c results in a seg fault under VS2008. I
beliveve this is fixed by chaning the line to ''g_free(format);''
--
Ticket URL: <http://sourceforge.net/apps/trac/bugle/ticket/86>
BuGLe <http://www.opengl.org/sdk/tools/BuGLe>
An open-source OpenGL debugger
|
|
From: bugle - T. i. <no...@so...> - 2011-05-11 06:25:47
|
#85: lock fails on Windows under msvc
-------------------------+--------------------------------------------------
Reporter: singing-tree | Owner: bmerry
Type: defect | Status: new
Priority: major | Component: Windows port
Version: 0.0.20101121 | Keywords:
-------------------------+--------------------------------------------------
Under Windows 7, a build compiled with VS2008 has following issue:
I am attempting to use gldb-gui to test BuGLe functionality. gldb-gui
starts and I am able to open the run dialog and input the path to my
desired OpenGL program. Upon starting the program a texture is loaded as
part of the program's start up which results in an exception during a call
to ''lock(void)'' of ''globjects.c''.
From what I can tell a NULL pointer is returned by the line
''else return *(object **) ans;''
in the ''bugle_object_get_current'' call resulting from lock. Incase it is
of note: ans is not NULL during the above statement.
I am unsure as to why a NULL is returned, and have had little success with
looking into the matter further thus far.
--
Ticket URL: <http://sourceforge.net/apps/trac/bugle/ticket/85>
BuGLe <http://www.opengl.org/sdk/tools/BuGLe>
An open-source OpenGL debugger
|
|
From: Bruce M. <bm...@gm...> - 2011-04-10 13:01:31
|
Hi Bryce This sounds like a new one to me - please do file it in trac. Unfortunately I'm in the process of moving jobs (and countries), so I have almost zero time to maintain bugle at the moment. Based on the stack trace, here's my best guess as to what is happening. The call to bugle_object_get_current_data is to extract data about objects stored in the namespace. To determine that, it first needs to find the current namespace (which is the innermost call in your trace). That information is stored in the current context (although a context never changes namespaces, it seems I found it easier just to have an idea of a current namespace for each context). The variable ans should point to the piece of the context storage that holds a pointer to the namespace for that context. Without being able to attach a debugger myself I think that's about all I can figure out, but I can guess that the most likely cause will be that bugle is getting confused about what the current context is - either because it's not intercepting the WGL calls (entirely possible - Windows support is nowhere near as tested as GLX), or because the app isn't making a context current (although I'd expect the app not to work in that case). > The data stored in ans comes from obj->views[view] in the > bugle_object_get_data function. > The views array contains data initialised by bugle_object_new via the line > (*info->constructor)(key, obj->views[j]); > The constructor function pointer is pointing to the globjects_data_init > function, which initialises globjects_data structs in some memory location > given a pointer. This pointer is from obj->views[j] in the case above. > This is where I fear I've made an error, as if the above is correct it would > mean that ans = bugle_object_get_current_data(klass->parent, > klass->parent_view); is a void* pointing to a globjects_data. As such the > *(object **)ans cast doesn't make sense (as far as I can tell). What I suspect you're missing is that when bugle_object_get_current calls bugle_object_get_current_data, it passes klass->parent, not klass. The view it gets back is initialized in bugle_object_class_new. Regards Bruce -- Dr Bruce Merry bmerry <@> gmail <.> com http://www.brucemerry.org.za/ http://blog.brucemerry.org.za/ |
|
From: Bryce V. D. <bv...@au...> - 2011-04-10 05:08:22
|
Hi,
I'm having an issue with BuGLe when attempting to use gldb on 32bit Windows
7, compiled with MSVC (VS9).
I'm attempting to use gldb to test and explore BuGLe's functionality, after
which I'm gonna dive a little deeper. Right now I'm having an issue stemming
from intercepting glBindTexture and the resulting BuGLe
bugle_thread_lock_lock call. I expect the issue is not specific to using
gldb, but have not attempted to replicate the issue under other
circumstances as I've been attempting to rectify it. The program I'm using
gldb to execute is a simple OpenGL program using QT which draws a textured
quad. The issue happens during init code to bind the texture.
A partial stack trace follows, note some of the line numbers may not be the
same as in the original source as I've added code to assist with debugging.
opengl32.dll!bugle_object_get_current(const object_class *
klass=0x00e7bea0) Line 161 C
opengl32.dll!bugle_object_get_current_data(const object_class *
klass=0x00e7bea0, unsigned int view=0) Line 169 + 0xd bytes C
opengl32.dll!lock() Line 60 + 0x11 bytes C
opengl32.dll!globjects_add_single(bugle_globjects_type
type=BUGLE_GLOBJECTS_TEXTURE, unsigned int target=3553, unsigned int
object=1, unsigned char (unsigned int)* is=0x63f441b8) Line 86 C
opengl32.dll!globjects_glBindTexture(function_call * call=0x0024f2b0,
const callback_data * data=0x0024f288) Line 121 + 0x32 bytes C
opengl32.dll!filters_run(function_call * call=0x0024f2b0) Line 722 +
0x10 bytes C
opengl32.dll!budgie_interceptor(function_call * call=0x0024f2b0) Line
222 + 0x9 bytes C
opengl32.dll!glBindTexture(unsigned int arg0=3553, unsigned int
arg1=1) Line 25454 + 0xc bytes C
QtGlTestProj.exe!SimpleGLWidget::loadTexture() Line 24 C++
Line 161 in the top stack frame is
> else return *(object **) ans;
>
however the cast and dereference results in a NULL pointer.
I'm currently trying to understand the relationships between the data types
and why this line is resulting in a NULL. Here's my current thought process:
- The data stored in ans comes from obj->views[view] in the
bugle_object_get_data
function.
- The views array contains data initialised by bugle_object_new via the
line (*info->constructor)(key, obj->views[j]);
- The constructor function pointer is pointing to the
globjects_data_initfunction, which initialises globjects_data structs
in some memory location
given a pointer. This pointer is from obj->views[j] in the case above.
- This is where I fear I've made an error, as if the above is correct it
would mean that ans = bugle_object_get_current_data(klass->parent,
klass->parent_view); is a void* pointing to a globjects_data. As such the
*(object **)ans cast doesn't make sense (as far as I can tell).
Would anyone be able to shed any light on what's going on here, or offer any
advice? I've had a look through Trac and didn't see any similar problems,
but wanted to check out the mailing list to see if I could resolve this
before I submit a ticket. Any help would be much appreciated.
Kind regards,
Bryce Van Dyk.
|
|
From: bugle - T. i. <no...@so...> - 2011-02-04 13:43:46
|
#84: build fails on fedora 14 (dsolink bug)
---------------------+------------------------------------------------------
Reporter: scontini | Owner: bmerry
Type: defect | Status: new
Priority: major | Component: other
Version: SVN | Keywords: dsolink f14
---------------------+------------------------------------------------------
http://fedoraproject.org/wiki/UnderstandingDSOLinkChange
scons: done reading SConscript files.
scons: Building targets ...
LINK build/gcc_gcc_gl_glx_x11_posix_release/tests/bugletest
/usr/bin/ld: build/gcc_gcc_gl_glx_x11_posix_release/tests/dlopen.o:
undefined reference to symbol 'dlopen@@GLIBC_2.1'
/usr/bin/ld: note: 'dlopen@@GLIBC_2.1' is defined in DSO /lib/libdl.so.2
so try adding it to the linker command line
/lib/libdl.so.2: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
scons: *** [build/gcc_gcc_gl_glx_x11_posix_release/tests/bugletest] Error
1
scons: building terminated because of errors.
--
Ticket URL: <http://sourceforge.net/apps/trac/bugle/ticket/84>
BuGLe <http://www.opengl.org/sdk/tools/BuGLe>
An open-source OpenGL debugger
|
|
From: bugle - T. i. <no...@so...> - 2011-02-02 20:17:53
|
#83: C++ compiler detection is broken
-------------------------+--------------------------------------------------
Reporter: bmerry | Owner: bmerry
Type: defect | Status: new
Priority: minor | Component: other
Version: 0.0.20101121 | Keywords:
-------------------------+--------------------------------------------------
When a user tried to compile on a system without g++, scons tried to run a
command called "o" instead of just complaining or defaulting to trying
g++.
--
Ticket URL: <http://sourceforge.net/apps/trac/bugle/ticket/83>
BuGLe <http://www.opengl.org/sdk/tools/BuGLe>
An open-source OpenGL debugger
|
|
From: bugle - T. i. <no...@so...> - 2010-11-19 20:59:04
|
#82: Configuration fails on OS X
-------------------------+--------------------------------------------------
Reporter: tfogal | Owner: bmerry
Type: defect | Status: new
Priority: major | Component: core
Version: 0.0.20100718 | Keywords:
-------------------------+--------------------------------------------------
A simple 'scons' fails because the configuration cannot find the glX
header.
The glX headers come with X11 (I think) on OS X, though they are of course
installed in strange places so if the script is just searching some
default paths it will not find it.
Apple platforms also have "agl" context manipulation functions, as an
alternative to glX.
The "best" way to get OpenGL on an apple platform is to add "-framework
OpenGL" to both compilation and link flags.
Here's the scons log:
{{{
scons: Reading SConscript files ...
Checking for C library m... yes
Checking for C header file stdint.h... yes
Checking for C function siglongjmp()... yes
Checking for GCC printf attribute... yes
Checking for GCC constructor attribute... yes
Checking for GCC hidden alias attribute... no
Checking for inline... no
Checking for __inline__... yes
Checking for C header file GL/glx.h... no
GL/glx.h not found
scons: Reading SConscript files ...
Checking for C library m... yes
Checking for C header file stdint.h... yes
Checking for C function siglongjmp()... yes
Checking for GCC printf attribute... yes
Checking for GCC constructor attribute... yes
Checking for GCC hidden alias attribute... no
Checking for inline... no
Checking for __inline__... yes
Checking for C header file GL/glx.h... no
GL/glx.h not found
}}}
--
Ticket URL: <http://sourceforge.net/apps/trac/bugle/ticket/82>
BuGLe <http://www.opengl.org/sdk/tools/BuGLe>
An open-source OpenGL debugger
|
|
From: bugle - T. i. <no...@so...> - 2010-08-22 09:32:26
|
#81: Support instanced draw calls for batch/triangle counts [patch]
-------------------------+--------------------------------------------------
Reporter: branan | Owner: bmerry
Type: enhancement | Status: new
Priority: enhancement | Component: filter-sets
Version: 0.0.20100718 | Keywords:
-------------------------+--------------------------------------------------
Comment(by bmerry):
The patch is incorrect - it multiplies the number of vertices before
turning that into a number of primitives, so for example with a triangle
strip of M vertices instanced N times, it will return M*N-2 triangles
instead of (M-2)*N. I've fixed this on trunk and added some tests to
verify the counting.
--
Ticket URL: <http://sourceforge.net/apps/trac/bugle/ticket/81#comment:3>
BuGLe <http://www.opengl.org/sdk/tools/BuGLe>
An open-source OpenGL debugger
|
|
From: bugle - T. i. <no...@so...> - 2010-08-21 20:51:38
|
#81: Support instanced draw calls for batch/triangle counts [patch]
-------------------------+--------------------------------------------------
Reporter: branan | Owner: bmerry
Type: enhancement | Status: new
Priority: enhancement | Component: filter-sets
Version: 0.0.20100718 | Keywords:
-------------------------+--------------------------------------------------
Comment(by bmerry):
These functions should now be supported on trunk, although it's not
tested. I'll leave the bug open pending tests, as well as support for all
the other new draw calls in GL3+.
--
Ticket URL: <http://sourceforge.net/apps/trac/bugle/ticket/81#comment:2>
BuGLe <http://www.opengl.org/sdk/tools/BuGLe>
An open-source OpenGL debugger
|
|
From: bugle - T. i. <no...@so...> - 2010-08-15 19:47:46
|
#81: Support instanced draw calls for batch/triangle counts [patch]
-------------------------+--------------------------------------------------
Reporter: branan | Owner: bmerry
Type: enhancement | Status: new
Priority: enhancement | Component: filter-sets
Version: 0.0.20100718 | Keywords:
-------------------------+--------------------------------------------------
Comment(by bmerry):
Thanks, that looks promising. I'll add it next time I get time to work on
bugle. As you've probably noticed, I've not been able to keep up with GL3+
features.
--
Ticket URL: <http://sourceforge.net/apps/trac/bugle/ticket/81#comment:1>
BuGLe <http://www.opengl.org/sdk/tools/BuGLe>
An open-source OpenGL debugger
|
|
From: bugle - T. i. <no...@so...> - 2010-08-11 15:43:28
|
#80: Segfault in trace
-------------------------+--------------------------------------------------
Reporter: branan | Owner: bmerry
Type: defect | Status: closed
Priority: major | Component: core
Version: 0.0.20100718 | Resolution: invalid
Keywords: |
-------------------------+--------------------------------------------------
Changes (by branan):
* status: new => closed
* resolution: => invalid
Comment:
>If you're passing a bad pointer (i.e. it doesn't point at 16 floats) then
I'd expect a segfault. Is that the case?
I changed some things around to fix some odd behavior I was seeing
elsewhere, and this seems to have gone away, so it is likely the case I
had an invalid index somewhere.
Sorry for the spurious report.
--
Ticket URL: <http://sourceforge.net/apps/trac/bugle/ticket/80#comment:2>
BuGLe <http://www.opengl.org/sdk/tools/BuGLe>
An open-source OpenGL debugger
|
|
From: bugle - T. i. <no...@so...> - 2010-08-11 07:40:07
|
#80: Segfault in trace
-------------------------+--------------------------------------------------
Reporter: branan | Owner: bmerry
Type: defect | Status: new
Priority: major | Component: core
Version: 0.0.20100718 | Keywords:
-------------------------+--------------------------------------------------
Comment(by bmerry):
> but I would still expect BuGLe to survine any series of GL commands that
the base implementation can survive.
That's not necessarily true. In this case, it looks like you're passing a
=location= of -1. glUniformMatrix4fv is defined to be a no-op in that
case, so the driver is probably not even looking at the matrix. The
tracer, on the other hand, need to look at the matrix data so that it can
dump it. If you're passing a bad pointer (i.e. it doesn't point at 16
floats) then I'd expect a segfault. Is that the case?
--
Ticket URL: <http://sourceforge.net/apps/trac/bugle/ticket/80#comment:1>
BuGLe <http://www.opengl.org/sdk/tools/BuGLe>
An open-source OpenGL debugger
|
|
From: bugle - T. i. <no...@so...> - 2010-08-11 06:34:03
|
#81: Support instanced draw calls for batch/triangle counts [patch]
-------------------------+--------------------------------------------------
Reporter: branan | Owner: bmerry
Type: enhancement | Status: new
Priority: enhancement | Component: filter-sets
Version: 0.0.20100718 | Keywords:
-------------------------+--------------------------------------------------
glDrawArraysInstancedARB and glDrawElementsInstancedARB are not counted
towards batch and triangle counts. This makes the statistics counts less
than helpful when using instancing.
Attached is a patch that adds the ARB instancing functions to
stats_primitives.c It counts each call to an instancing entrypoint as 1
batch with elementcount*indexcount elements.
--
Ticket URL: <http://sourceforge.net/apps/trac/bugle/ticket/81>
BuGLe <http://www.opengl.org/sdk/tools/BuGLe>
An open-source OpenGL debugger
|
|
From: bugle - T. i. <no...@so...> - 2010-08-11 00:39:23
|
#80: Segfault in trace
-------------------------+--------------------------------------------------
Reporter: branan | Owner: bmerry
Type: defect | Status: new
Priority: major | Component: core
Version: 0.0.20100718 | Keywords:
-------------------------+--------------------------------------------------
Both my application and bugle were compield with GCC 4.5.0.
I know for sure that my GL code is broken (I'm in the middle of rewriting
some things, so there are no shaders defined even though glUniform is
called), but I would still expect BuGLe to survine any series of GL
commands that the base implementation can survive.
{{{
chain trace
{
filterset trace
filterset showerror
filterset log
{
filename "bugle.log"
# flush "yes"
}
}
}}}
{{{
#0 0x00007ffff5532daf in _budgie_dump_TYPE_7GLfloat
(value=0x1ffffdfa46a7e0, count=-1, writer=0x99d900) at
build/gcc_gcc_gl_glx_x11_posix_debug/budgielib/tables.c:722
#1 0x00007ffff5530dfc in budgie_dump_any_type (type=59,
value=0x1ffffdfa46a7e0, length=-1, writer=0x99d900) at
src/budgielib/reflect.c:220
#2 0x00007ffff5535c07 in _budgie_dump_TYPE_A4_7GLfloat
(value=0x1ffffdfa46a7e0, count=-1, writer=0x99d900) at
build/gcc_gcc_gl_glx_x11_posix_debug/budgielib/tables.c:1748
#3 0x00007ffff5530dfc in budgie_dump_any_type (type=123,
value=0x1ffffdfa46a7e0, length=-1, writer=0x99d900) at
src/budgielib/reflect.c:220
#4 0x00007ffff5532553 in _budgie_dump_TYPE_6GLmat4
(value=0x1ffffdfa46a7e0, count=-1, writer=0x99d900) at
build/gcc_gcc_gl_glx_x11_posix_debug/budgielib/tables.c:533
#5 0x00007ffff5530dfc in budgie_dump_any_type (type=44,
value=0x1ffffdfa46a7e0, length=-1, writer=0x99d900) at
src/budgielib/reflect.c:220
#6 0x00007ffff5533499 in _budgie_dump_TYPE_7pGLmat4
(value=0x7fffffffddf8, count=1, writer=0x99d900) at
build/gcc_gcc_gl_glx_x11_posix_debug/budgielib/tables.c:879
#7 0x00007ffff5530dfc in budgie_dump_any_type (type=71,
value=0x7fffffffddf8, length=1, writer=0x99d900) at
src/budgielib/reflect.c:220
#8 0x00007ffff7ac55c5 in budgie_call_parameter_dump (call=0x7fffffffde10,
param=3, writer=0x99d900) at src/budgielib/addresses.c:96
#9 0x00007ffff7ac5650 in budgie_dump_any_call (call=0x7fffffffde10,
indent=0, writer=0x99d900) at src/budgielib/addresses.c:109
#10 0x00007ffff0bc9b4f in trace_callback (call=0x7fffffffde10,
data=0x7fffffffdda0) at src/filters/trace.c:39
#11 0x00007ffff7ac04f0 in filters_run (call=0x7fffffffde10) at
src/filters.c:722
#12 0x00007ffff7abef8c in budgie_interceptor (call=0x7fffffffde10) at
src/interceptor.c:222
#13 0x00007ffff7b38390 in glUniformMatrix4fv (arg0=-1, arg1=1, arg2=0
'\000', arg3=0x1ffffdfa46a7e0) at
build/gcc_gcc_gl_glx_x11_posix_debug/budgielib/lib.c:57791
}}}
--
Ticket URL: <http://sourceforge.net/apps/trac/bugle/ticket/80>
BuGLe <http://www.opengl.org/sdk/tools/BuGLe>
An open-source OpenGL debugger
|
|
From: bugle - T. i. <no...@so...> - 2010-07-18 14:08:35
|
#79: stats_fragment might be broken on Windows
-------------------------+--------------------------------------------------
Reporter: bmerry | Owner: bmerry
Type: defect | Status: new
Priority: major | Component: Windows port
Version: 0.0.20100718 | Keywords:
-------------------------+--------------------------------------------------
I observed this while testing on a Windows XP machine with (somewhat old)
NVIDIA drivers, but I may have fixed it since then.
--
Ticket URL: <http://sourceforge.net/apps/trac/bugle/ticket/79>
BuGLe <http://www.opengl.org/sdk/tools/BuGLe>
An open-source OpenGL debugger
|
|
From: bugle - T. i. <no...@so...> - 2010-07-18 14:03:45
|
#78: More tests required
-------------------------+--------------------------------------------------
Reporter: bmerry | Owner: bmerry
Type: task | Status: new
Priority: major | Component: tests
Version: 0.0.20100718 | Keywords:
-------------------------+--------------------------------------------------
The set of tests is rather incomplete. Some ideas for more tests:
- unit tests on I/O layer
- unit tests on socket support
- tests that generate visual output should have run, say, glxgears in a
standard way instead of being tested ad-hoc
- there are probably more automated tests that can be run on filters.
--
Ticket URL: <http://sourceforge.net/apps/trac/bugle/ticket/78>
BuGLe <http://www.opengl.org/sdk/tools/BuGLe>
An open-source OpenGL debugger
|
|
From: bugle - T. i. <no...@so...> - 2010-07-18 14:00:11
|
#77: Make gldb-common less platform-specific
-------------------------+--------------------------------------------------
Reporter: bmerry | Owner: bmerry
Type: enhancement | Status: new
Priority: minor | Component: debugger
Version: 0.0.20100718 | Keywords:
-------------------------+--------------------------------------------------
It currently has lots of platform-specific code for creating the child
process, getting handles and so on. Some of that is inevitable, but could
be reduced by making it depend on glib, or moving it into the porting
layer.
--
Ticket URL: <http://sourceforge.net/apps/trac/bugle/ticket/77>
BuGLe <http://www.opengl.org/sdk/tools/BuGLe>
An open-source OpenGL debugger
|
|
From: bugle - T. i. <no...@so...> - 2010-07-18 13:58:47
|
#76: Automated tests don't pick up opengl32.dll on Windows
-------------------------+--------------------------------------------------
Reporter: bmerry | Owner: bmerry
Type: defect | Status: new
Priority: major | Component: Windows port
Version: 0.0.20100718 | Keywords:
-------------------------+--------------------------------------------------
The system path always comes ahead of $PATH, so it is not sufficient to
put opengl32.dll on the path. It needs to be copied to the
build/<variant>/test directory as part of the test process.
--
Ticket URL: <http://sourceforge.net/apps/trac/bugle/ticket/76>
BuGLe <http://www.opengl.org/sdk/tools/BuGLe>
An open-source OpenGL debugger
|
|
From: bugle - T. i. <no...@so...> - 2010-07-18 13:56:40
|
#7: Support generating wrapper functions into separate shared objects
-------------------------+--------------------------------------------------
Reporter: bmerry | Owner: bmerry
Type: enhancement | Status: new
Priority: enhancement | Component: budgie
Version: 0.0.20090311 | Keywords:
-------------------------+--------------------------------------------------
Comment(by bmerry):
As part of this, it should also be possible to associate functions with
specific libraries for the purposes of obtaining addresses. Currently
things don't necessarily work on ELF because GLES symbols are queried from
libEGL and vice versa.
--
Ticket URL: <http://sourceforge.net/apps/trac/bugle/ticket/7#comment:1>
BuGLe <http://www.opengl.org/sdk/tools/BuGLe>
An open-source OpenGL debugger
|