crash bei wxClientDC(this)?!?

Ist das innerhalb eines wxPaintEvents?
Und wird der dc per referenz übergeben oder als kopie?

mael15

hier nochmal die komplette methode, es wird keine dc übergeben:

void PlotterBaseCont::doStepDirectly( int start, int stop )
{
	if(IsEnabled() && IsShown()){	
		wxClientDC dc(this);
		if(dc.IsOk())
			doStep(start, stop, dc);
	}
}   // <- hier zeigt vs den fehler an

aufgerufen wird die methode, nachdem ein d/a wandler neue daten in einen buffer geschrieben hat, die dann angezeigt werden sollen.

doStep ist virtual, könnte also vielleicht der fehler in der abgeleiteten klasse stecken, ohne dass vs das anzeigen würde?
danke!

mael15

teilweise habe ich auch crashs in zeile vier des im vorigen post stehenden codes, also in wxClientDC dc(this);

wie könnte das passieren?

mael15

mittlerweile habe ich ausschließen können, dass der crash in der abgeleiteten klasse ausgelöst wird. es ist also tatsächlichen wxClientDC(this) das problem.

aber wie zur hölle kann das sein?!?! hat niemand eine idee?

oder kann ich das problem

assert "m_refData->m_count > 0" failed in wxObject::UnRef(): invalid ref data count [in child thread]

irgendwie abfangen?

mael15

das problem scheint gelöst. wie die stelle des fehlers schon nahelegte, gab es beim schließen des programms manchmal bereits kein "this" mehr, die methode worde aber gerade noch aufgerufen von einem callback aus einem anderen thread, der wohl noch lief.

ich habe es gelöst, indem ich beim schließen des programms so früh wie möglich das onCloseEvent abgefangen und ein bool isShuttingDown gesetzt habe. die oben stehende methode wird dann nicht mehr aufgerufen, weil der callback auf isShuttingDown testet.

danke für eure ideen!

mael15

das problem ist leider doch nicht gelöst. ich habe versucht, es dadruch zu ändern, dass ich aus dem wxClientDC eine wxPaintDC in einem paintEvent gemacht habe. aber auch dort kommt wie vorher an der stelle wxClientDC dc(this) dann bei wxPaintDC dc(this) derselbe fehler nach einer immer unterschiedlichen zeitspanne. der fehler ist genauso

assert "m_refData->m_count > 0" failed in wxObject::UnRef(): invalid ref data count

kann ich irgendwie infos zu m_refData->m_count auslesen?
was könnte ich noch probieren?! es treibt mich zur verzweiflung...

danke!

phlox81

Klingt für mich danach, das das Problem wo anders liegt, und erst dort dann durchschlägt.
Wo und wie erzeugst du das Objekt welches diesen Code enthält?

mael15

das objekt ist ein plotter, der aktiv wird, sobald daten in einen buffer geschrieben werden. der plotter wird gleich zu programmstart erzeugt und läuft auch einige duzent sekunden, bevor es irgendwann zum crash kommt. die benachrichtigung des plotters läuft bisher über einen callback. ich werde mal versuchen, den callback durch einen observer zu ersetzen. der gedanke war, dass der callback vielleicht als nicht-wxwidgets konstrukt bzw. eher c++ untypischere technik probleme machen könnte.
was meinst du?

hier ein bild der fehlermeldung:
http://gemini-sites.de/wxPaintFehler.gif

mael15

es war wahrschinlich ein handle leak, genaue beschreibung hier: http://www.c-plusplus.net/forum/p2079637#2079637.
danke für eure hilfe!

mael15

leider besteht das problem nach wie vor.
zu unregelmäßigen zeitpunkten bekomme ich den fehler

assert "m_refData->m_count > 0" failed in wxObject::UnRef(): invalid ref data count

an einer vermeindlich harmlose codestelle:

allBtmpMutex->Lock();
wxBitmap *all = getAllBitmap();
if(all->IsOk()){
	wxClientDC dc(this);               // crash hier oder
	if(dc.IsOk()){
		dc.DrawBitmap(*all, 0, 0);     // hier
	}
}
allBtmpMutex->Unlock();

was ich nicht verstehe ist, dass wenn ich mir this->getRefData() VOR dem crash ansehen will, es auch dann nicht initialisiert ist.

ich dachte auch schon, es wäre vielleicht ein memory problem, das erst immer an dieser stelle durchschlägt. ich habe aber das programm mit application verifier mit dem standard checks laufen lassen und keinerlei probleme gemeldet bekommen.

ich habe diese crashs jetzt schon seit monaten und etliche tage darauf verwendet, um dem problem näher zu kommen.
etwas, was mich daran hindert ist, dass ich den call stack nicht lückenlos zurückverfolgen kann, weil ich keine symbole für wxWidgets laden kann (siehe http://www.c-plusplus.net/forum/288102).

hier mein call stack beim absturz:

ntdll.dll!_DbgBreakPoint@0()
wxbase28ud_vc_custom.dll!007bb739()
[Unten angegebene Rahmen sind möglicherweise nicht korrekt und/oder fehlen, keine Symbole geladen für wxbase28ud_vc_custom.dll]
wxbase28ud_vc_custom.dll!007bbb04()
wxbase28ud_vc_custom.dll!007bb029()
wxbase28ud_vc_custom.dll!007bb814()
wxbase28ud_vc_custom.dll!0083bf82()
wxbase28ud_vc_custom.dll!0083bf0f()
wxbase28ud_vc_custom.dll!007bd12b()
wxmsw28ud_core_vc_custom.dll!009f1f24()
wxmsw28ud_core_vc_custom.dll!00a43633()
wxmsw28ud_core_vc_custom.dll!00a43713()
wxmsw28ud_core_vc_custom.dll!00af8d6a()
wxmsw28ud_core_vc_custom.dll!00afdaa7()
wxmsw28ud_core_vc_custom.dll!00afdc3f()
wxmsw28ud_core_vc_custom.dll!00afdc0c() // <- ab hier keine symbole vorhanden
> myProg.exe!PlotterBaseCont::doStepDirectly(int start=0, int stop=24) Zeile 76 + 0x12 Bytes C++
myProg.exe!ModePanelFrame::onSampleData() Zeile 247 C++
myProg.exe!raiseSampleEvent() Zeile 71 C++
da.dll!onSampleData() Zeile 30 + 0x8 Bytes C++
da.dll!EveryNCallback(void * taskHandle=0x6deb1cc0, long everyNsamplesEventType=1, unsigned long nSamples=25, void * callbackData=0x0208de50) Zeile 133 C++
nicaiu.dll!6d9cce13()
nidmxfu.dll!6db9e6da()
nidmxfu.dll!6db85d7b()
nipalu.dll!6400cbc3()
nipalu.dll!6402f97a()
nipalut.dll!6450113e()
kernel32.dll!7c80b729()

die niXYZ.dll´s am ende sind von national instruments, deren gerät erzeugt die daten, die dann auf dem bildschirm dargestellt werden.

hat jemand noch irgendeine idee dazu? ich dreh langsam durch....
danke!