Dmitry Timoshkov dmitry@baikal.ru wrote:
dlls/gdi32/gdiobj.c | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-)
What's the reason for the 'rejected' status?
Dmitry Timoshkov dmitry@baikal.ru writes:
Dmitry Timoshkov dmitry@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@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 Timoshkov dmitry@baikal.ru writes:
Alexandre Julliard julliard@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@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 Timoshkov dmitry@baikal.ru writes:
Is it OK to add a prefix manually to the MESSAGE calls?
No, that wouldn't handle +tid and the like.
Alexandre Julliard julliard@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 Timoshkov dmitry@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@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.
-
Alexandre Julliard -
Dmitry Timoshkov