Обсуждение: Further crashes

When trying to add a new server, I get this crash:

(gdb) c
Continuing.
*** malloc[2954]: Deallocation of a pointer not malloced: 0xbfffea10;
This could be a double free(), or free() called with the middle of an
allocated block; Try setting environment variable MallocHelp to see
tools to help debug

Program received signal EXC_BAD_ACCESS, Could not access memory.
0x00076914 in frmConnect::GetDescription() (this=0xbfffea10) at
ui/frmConnect.cpp:145
145         return txtDescription->GetValue();
(gdb)

And the backtrace:

(gdb) bt
#0  0x00076914 in frmConnect::GetDescription() (this=0xbfffea10) at
ui/frmConnect.cpp:145
#1  0x0003db88 in pgServer::Connect(wxFrame*, bool) (this=0xf44a1b0,
form=0xb853600, lockFields=false) at schema/pgServer.cpp:108
#2  0x0006e538 in frmMain::OnAddServer(wxCommandEvent&)
(this=0xb853600, ev=@0xbfffefa0) at ui/events.cpp:539
#3  0x0011bcdc in wxAppConsole::HandleEvent(wxEvtHandler*, void
(wxEvtHandler::*)(wxEvent&), wxEvent&) const (this=0xb314450,
handler=0xb853600, func={__pfn = (void ( wxEvtHandler::*)(wxEvent &,))
56422, __delta = 0}, event=@0xbfffefa0) at
../src/common/appbase.cpp:288
#4  0x0011e154 in
wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&,
wxEvtHandler*, wxEvent&) (entry=@0x73b45c, handler=0xb853600,
event=@0xbfffefa0) at ../src/common/event.cpp:1169
#5  0x0011d2b8 in wxEventHashTable::HandleEvent(wxEvent&,
wxEvtHandler*) (this=0x73b36c, event=@0xbfffefa0, self=0xb853600) at
../src/common/event.cpp:837
#6  0x0011e46c in wxEvtHandler::ProcessEvent(wxEvent&) (this=0xb853600,
event=@0xbfffefa0) at ../src/common/event.cpp:1231
#7  0x0012e8f8 in wxWindowBase::TryParent(wxEvent&) (this=0xb5b8a00,
event=@0xbfffefa0) at ../src/common/wincmn.cpp:2230
#8  0x0011e500 in wxEvtHandler::ProcessEvent(wxEvent&) (this=0xb5b8a00,
event=@0xbfffefa0) at ../src/common/event.cpp:1244
#9  0x00317e4c in wxToolBarBase::OnLeftClick(int, bool)
(this=0xb5b8a00, id=101, toggleDown=false) at
../src/common/tbarbase.cpp:576
#10 0x0031991c in wxToolBar::MacHandleControlClick(void*, short, bool)
(this=0xb5b8a00, control=0xb5b9670, controlpart=10) at
../src/mac/toolbar.cpp:409
#11 0x0031a338 in wxToolBar::OnMouse(wxMouseEvent&) (this=0xb5b8a00,
event=@0xbffff3e0) at ../src/mac/toolbar.cpp:611
#12 0x0011bcdc in wxAppConsole::HandleEvent(wxEvtHandler*, void
(wxEvtHandler::*)(wxEvent&), wxEvent&) const (this=0xb314450,
handler=0xb5b8a00, func={__pfn = (void ( wxEvtHandler::*)(wxEvent &,))
406563, __delta = 0}, event=@0xbffff3e0) at
../src/common/appbase.cpp:288
#13 0x0011e154 in
wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&,
wxEvtHandler*, wxEvent&) (entry=@0x86e37c, handler=0xb5b8a00,
event=@0xbffff3e0) at ../src/common/event.cpp:1169
#14 0x0011d2b8 in wxEventHashTable::HandleEvent(wxEvent&,
wxEvtHandler*) (this=0x86e364, event=@0xbffff3e0, self=0xb5b8a00) at
../src/common/event.cpp:837
#15 0x0011e46c in wxEvtHandler::ProcessEvent(wxEvent&) (this=0xb5b8a00,
event=@0xbffff3e0) at ../src/common/event.cpp:1231
#16 0x001a719c in wxWindow::MacDispatchMouseEvent(wxMouseEvent&)
(this=0xb5b8a00, event=@0xbffff3e0) at ../src/mac/window.cpp:1578
#17 0x001a6ea8 in wxWindow::MacDispatchMouseEvent(wxMouseEvent&)
(this=0xb853600, event=@0xbffff3e0) at ../src/mac/window.cpp:1529
#18 0x001abf74 in wxTopLevelWindowMac::MacFireMouseEvent(unsigned
short, int, int, unsigned, long) (this=0xb853600, kind=1, x=204, y=196,
modifiers=0, timestamp=11648548) at ../src/mac/toplevel.cpp:996
#19 0x001a9d68 in MouseEventHandler(OpaqueEventHandlerCallRef*,
OpaqueEventRef*, void*) (handler=0xbffff740, event=0xb33fcc0,
data=0xb853600) at ../src/mac/toplevel.cpp:288
#20 0x001aa6a8 in wxMacWindowEventHandler(OpaqueEventHandlerCallRef*,
OpaqueEventRef*, void*) (handler=0xbffff740, event=0xb33fcc0,
data=0xb853600) at ../src/mac/toplevel.cpp:453
#21 0x927d24e4 in DispatchEventToHandlers ()
#22 0x927d2758 in SendEventToEventTargetInternal ()
#23 0x927e4be8 in SendEventToEventTarget ()
#24 0x927f3368 in HandleMouseEventForWindow(OpaqueWindowPtr*,
OpaqueEventRef*, unsigned short) ()
#25 0x927e8c84 in HandleMouseEvent(OpaqueEventRef*) ()
#26 0x927e3188 in
ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*,
OpaqueEventRef*, void*) ()
#27 0x927d25a0 in DispatchEventToHandlers ()
#28 0x927d2758 in SendEventToEventTargetInternal ()
#29 0x927e4be8 in SendEventToEventTarget ()
#30 0x00146438 in wxApp::MacHandleOneEvent(void*) (this=???, evr=???)
at ../src/mac/app.cpp:1400
#31 0x00146398 in wxApp::MacDoOneEvent() (this=0xb314450) at
../src/mac/app.cpp:1342
#32 0x00145c94 in wxApp::MainLoop() (this=0xb314450) at
../src/mac/app.cpp:1094
#33 0x001528f8 in wxAppBase::OnRun() (this=0xb314450) at
../src/common/appcmn.cpp:330
#34 0x00119b68 in wxEntry(int&, wchar_t**) (argc=@0xbffffcb8,
argv=0xb313d50) at ../src/common/init.cpp:408
#35 0x00119c80 in wxEntry(int&, char**) (argc=@0xbffffcb8,
argv=0xbffffd50) at ../src/common/init.cpp:455
#36 0x00002b5c in main (argc=1, argv=0xbffffd50) at pgAdmin3.cpp:78
(gdb)

Also, attached is the way the add server dialog looks on the Mac.
There seems to be some kind of size issue.

ahp

Adam H.Pendleton wrote:

> When trying to add a new server, I get this crash:
>
> (gdb) c
> Continuing.
> *** malloc[2954]: Deallocation of a pointer not malloced: 0xbfffea10;
> This could be a double free(), or free() called with the middle of an
> allocated block; Try setting environment variable MallocHelp to see
> tools to help debug
>
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> 0x00076914 in frmConnect::GetDescription() (this=0xbfffea10) at
> ui/frmConnect.cpp:145
> 145         return txtDescription->GetValue();
> (gdb)
>
> And the backtrace:
>
> (gdb) bt
> #0  0x00076914 in frmConnect::GetDescription() (this=0xbfffea10) at
> ui/frmConnect.cpp:145
> #1  0x0003db88 in pgServer::Connect(wxFrame*, bool) (this=0xf44a1b0,
> form=0xb853600, lockFields=false) at schema/pgServer.cpp:108

Hm, seems the txtDescription isn't valid; why? When reviewing the code
in frmConnect, I wonder about those Destroy() in OnOk() and OnCancel();
looks dubious. I'll check this later.

> Also, attached is the way the add server dialog looks on the Mac.
> There seems to be some kind of size issue.
>
This is probably our well-known font inheritance problem. Pplease verify
this by adding SetFont(parent->GetFont()) in src/mac/control.cpp line
397 (after SetSize....)

Regards,
Andreas

Hi

> This is probably our well-known font inheritance problem. Pplease verify
> this by adding SetFont(parent->GetFont()) in src/mac/control.cpp line
> 397 (after SetSize....)

The current state in CVS would not allow this to work, as I have not yet
committed the changes to textctrl needed for SetFont. I hope to have all
changes ready for the new gui implementation based on composite windows and
HIViews this week.

Best,

Stefan

Stefan Csomor wrote:

>Hi
>
>
>
>>This is probably our well-known font inheritance problem. Pplease verify
>>this by adding SetFont(parent->GetFont()) in src/mac/control.cpp line
>>397 (after SetSize....)
>>
>>
>
>The current state in CVS would not allow this to work, as I have not yet
>committed the changes to textctrl needed for SetFont. I hope to have all
>changes ready for the new gui implementation based on composite windows and
>HIViews this week.
>
>

So we'll have to wait a bit. Stefan, it appears to me that that
MacPostControlCreate is just the right place to set the font to the
parent's font as default. I'm not sure about colours, maybe actually
InheritAttributes() is the correct thing to put here
(ShouldInheritColours should do the job, right?)

Regards
Andreas

> So we'll have to wait a bit. Stefan, it appears to me that that
> MacPostControlCreate is just the right place to set the font to the
> parent's font as default. I'm not sure about colours, maybe actually
> InheritAttributes() is the correct thing to put here
> (ShouldInheritColours should do the job, right?)

Hi

Yes this is the single point of entry that now every wxWindow passes
through, but the thing is even more complicated on mac, with the new
compositing design inheriting colors is not possible at all anymore in a
reasonable way, so we must in most of the cases let the system decide what
our correct background color is (eg group boxes get darker for each level).
If we start setting it explicitly it is immediately clear that it is not a
true mac app. So most of the controls render transparently, and embedding
controls like notebooks and group boxes have different shades of gray.

For the size of different controls: on mac we have two (on panther three)
different rendering sizes of controls (including their fonts) normal, small
and mini. You will be able to set the default rendering on a wxSystemOptions
level and already now you can set it on each control individually by
SetWindowVariant(wxWINDOW_VARIANT_NORMAL , SMALL etc). I've also implemented
the latter call in wincmn, so that this translates into smaller control
fonts on platforms that don't allow scaling the control rendering itself. I
hope to have a degree of completeness that deserves committing by next week.

Best Regards,

Stefan

Stefan Csomor wrote:

>true mac app. So most of the controls render transparently, and embedding
>controls like notebooks and group boxes have different shades of gray.
>
I already suspected the color thing wouldn't be that easy.

>
>
>For the size of different controls: on mac we have two (on panther three)
>different rendering sizes of controls (including their fonts) normal, small
>and mini. You will be able to set the default rendering on a wxSystemOptions
>level and already now you can set it on each control individually by
>SetWindowVariant(wxWINDOW_VARIANT_NORMAL , SMALL etc). I've also implemented
>the latter call in wincmn, so that this translates into smaller control
>fonts on platforms that don't allow scaling the control rendering itself.
>

I'm not sure, is this the reinvention of the wheel? Using DlgUnit sizing
will resize the control according to the font used. We certainly don't
want to set each window's font individually, it's right the opposite: we
set the parent, and all childs will use that font (for display and size
calculation) unless changed afterward.

We have well-designed dialogs that provide exactly the space needed for
each control's contents (relative to the font). We certainly don't need
an additional mechanism for changing the rendering. Or is
SetWindowVariant just about GetBestSize etc? I'd understand that, but we
don't use it anyway.

Regards,
Andreas

Stefan Csomor wrote:

>$
>
>
>>I'm not sure, is this the reinvention of the wheel? Using DlgUnit sizing
>>will resize the control according to the font used. We certainly don't
>>want to set each window's font individually, it's right the opposite: we
>>set the parent, and all childs will use that font (for display and size
>>calculation) unless changed afterward.
>>
>>
>
>The situation on mac is that you set the rendering of everything that the
>control does, eg you have a smaller checkbox icon, a smaller tab size, a
>smaller scrollbar etc. font size and control rendering must go together,
>while you can explicitly change the font it is not going to provide you with
>the true mac l&f. You can set by a wxsys-option whether the default
>rendering should be normal or small.
>
>
I see. We'll have to inspect what it will really look like in the end.

>You cannot use dialog units for everything on mac anyway, as eg notebooks
>use up a lot more space than on windows, regardless of the font used. So
>only sizers can isolate from these differences.
>
>
Sigh... We'll have to check how big the discrepancies are. We use
notebooks regularly, but in a very strict way so we might be able to
handle it. I'm an explicit enemy of sizers if the dialog contents isn't
sizeable at all (33 of 36 dialogs have fixed contents, and those 3 where
hard work to resize in a sensible way)

Anyhow, it appears that we should wait until you finished your commits
to see what situation we really have to deal with.

Regards,
Andreas