Re: gdi32: Make output of dumping GDI objects more compact.
Dmitry Timoshkov <dmitry(a)baikal.ru> wrote:
--- dlls/gdi32/gdiobj.c | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-)
What's the reason for the 'rejected' status? -- Dmitry.
Dmitry Timoshkov <dmitry(a)baikal.ru> writes:
Dmitry Timoshkov <dmitry(a)baikal.ru> wrote:
--- dlls/gdi32/gdiobj.c | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-)
What's the reason for the 'rejected' status?
Traces without prefixes are confusing when they are interleaved with other things. -- Alexandre Julliard julliard(a)winehq.org
Alexandre Julliard <julliard(a)winehq.org> wrote:
Traces without prefixes are confusing when they are interleaved with other things.
This dump is being printed only in the emergency case, so, this is not really a "trace". Besides there are other places in Wine which use the same style: 'if (TRACE_ON()) MESSAGE();', what makes this dumping functions different from them? -- Dmitry.
Dmitry Timoshkov <dmitry(a)baikal.ru> writes:
Alexandre Julliard <julliard(a)winehq.org> wrote:
Traces without prefixes are confusing when they are interleaved with other things.
This dump is being printed only in the emergency case, so, this is not really a "trace". Besides there are other places in Wine which use the same style: 'if (TRACE_ON()) MESSAGE();', what makes this dumping functions different from them?
In general, these are because they don't print full lines. If they do, they should be fixed. All traces should have a trace prefix. -- Alexandre Julliard julliard(a)winehq.org
Alexandre Julliard <julliard(a)winehq.org> wrote:
In general, these are because they don't print full lines. If they do, they should be fixed. All traces should have a trace prefix.
Is it OK to add a prefix manually to the MESSAGE calls? -- Dmitry.
Alexandre Julliard <julliard(a)winehq.org> wrote:
Is it OK to add a prefix manually to the MESSAGE calls?
No, that wouldn't handle +tid and the like.
As a person, who have debugged and fixed quite a bit of GDI handle leaks, and who actually have introduced that facility in the first place, I can say, that an ability to see each line of GDI handle table prefixed with 'dump_gdi_objects:', thread id, or whatever doesn't help at all, but an ability to see more information on the screen wihout need to scroll forth and back, an ability to quickly figure out some pattern in that table really does. -- Dmitry.
Dmitry Timoshkov <dmitry(a)baikal.ru> writes:
As a person, who have debugged and fixed quite a bit of GDI handle leaks, and who actually have introduced that facility in the first place, I can say, that an ability to see each line of GDI handle table prefixed with 'dump_gdi_objects:', thread id, or whatever doesn't help at all, but an ability to see more information on the screen wihout need to scroll forth and back, an ability to quickly figure out some pattern in that table really does.
I'm sure everybody thinks the traces they are interested in deserve a different format, but that's not possible for obvious reasons. Just learn to use grep and sed. -- Alexandre Julliard julliard(a)winehq.org
Alexandre Julliard <julliard(a)winehq.org> wrote:
As a person, who have debugged and fixed quite a bit of GDI handle leaks, and who actually have introduced that facility in the first place, I can say, that an ability to see each line of GDI handle table prefixed with 'dump_gdi_objects:', thread id, or whatever doesn't help at all, but an ability to see more information on the screen wihout need to scroll forth and back, an ability to quickly figure out some pattern in that table really does.
I'm sure everybody thinks the traces they are interested in deserve a different format, but that's not possible for obvious reasons. Just learn to use grep and sed.
Unfortunately that's not always possible, for instance the log created by the app in the bug 29894 is more than 6 Gb. And once I see a suspect GDI handle, I want to see where it was created and how used, if that's wrong handle, I'd like to try another one from the same place of the log. -- Dmitry.
participants (2)
-
Alexandre Julliard -
Dmitry Timoshkov