Invalid write in document window?

Linux
1

hello,

i just ran some valgrind sessions to spot some possible memory leaks in my application.
whenever i create a document window I get an “invalid write error”

==22377== Invalid write of size 4 ==22377== at 0x807A0ED: juce::DocumentWindow::lookAndFeelChanged() (juce_DocumentWindow.cpp:290) ==22377== by 0x807A207: juce::DocumentWindow::parentHierarchyChanged() (juce_DocumentWindow.cpp:316) ==22377== by 0x805D5DD: juce::Component::internalHierarchyChanged() (juce_Component.cpp:1369) ==22377== by 0x805B260: juce::Component::addToDesktop(int, void*) (juce_Component.cpp:516) ==22377== by 0x807C177: juce::ResizableWindow::lookAndFeelChanged() (juce_ResizableWindow.cpp:347) ==22377== by 0x807A1ED: juce::DocumentWindow::lookAndFeelChanged() (juce_DocumentWindow.cpp:311) ==22377== by 0x80791BC: juce::DocumentWindow::DocumentWindow(juce::String const&, juce::Colour const&, int, bool) (juce_DocumentWindow.cpp:65) ==22377== by 0x804E75E: MainWindow::MainWindow() (testproject.cpp:14) ==22377== by 0x804E8EC: juceTest::initialise(juce::String const&) (testproject.cpp:50) ==22377== by 0x8054220: juce::JUCEApplication::main(juce::String&, juce::JUCEApplication*) (juce_Application.cpp:197) ==22377== by 0x80546A8: juce::JUCEApplication::main(int, char**, juce::JUCEApplication*) (juce_Application.cpp:285) ==22377== by 0x804E6CF: main (testproject.cpp:86) ==22377== Address 0x5db9f38 is 0 bytes after a block of size 248 alloc'd ==22377== at 0x4025390: operator new(unsigned int) (vg_replace_malloc.c:214) ==22377== by 0x804E8E0: juceTest::initialise(juce::String const&) (testproject.cpp:50) ==22377== by 0x8054220: juce::JUCEApplication::main(juce::String&, juce::JUCEApplication*) (juce_Application.cpp:197) ==22377== by 0x80546A8: juce::JUCEApplication::main(int, char**, juce::JUCEApplication*) (juce_Application.cpp:285) ==22377== by 0x804E6CF: main (testproject.cpp:86)

i tried it with various juce versions. 1.47 1.5 and something near the tip :wink:

atm i’m using a simple demo code

#include "juce_AppConfig.h"
#include "./../GitJuce/juce/juce_Config.h"
#include "./../GitJuce/juce/juce.h"

class MainWindow : public DocumentWindow
{
public:
	MainWindow()
	:DocumentWindow(T("BenennMich"),
                          Colour(0xffffffff), 
                          DocumentWindow::allButtons,
                          true)
	{
		setSize(200,100);
		setVisible(true);
	}

};
//==============================================================================
class juceTest : public JUCEApplication
{
    MainWindow *mainWin;

public:
    //==============================================================================
    juceTest()
        : mainWin (0)
    {
    }

    ~juceTest()
    {
    }

    //==============================================================================

    void systemRequestedQuit() {
		quit();
    }

    void initialise (const String& commandLine)
    {
  			mainWin = new MainWindow();
   }

    void shutdown()
    {
        // clear up..
        if (mainWin != 0)
            delete mainWin;
    }

    //==============================================================================
    const String getApplicationName()
    {
        return T("test for JUCE");
    }

    const String getApplicationVersion()
    {
        return T("1.0");
    }

    bool moreThanOneInstanceAllowed()
    {
        return true;
    }

    void anotherInstanceStarted (const String& commandLine)
    {
    }
};


//==============================================================================
// This macro creates the application's main() function..
START_JUCE_APPLICATION (juceTest);

this test application starts normal however, the window is seen… but this invalid write is giving me a headdache, because it seems my main project crashes because of heap corruption on the next initialisation following a “… = new DocumentWindow(…);”.
is this possible?
any help would be appreciated.

edit:
running the juce themo through valgrind doesn’t show any invalid writes…
so something must be wrong with my above code

2

so far no luck finding the source of the problem.
it’s caused by some code in line 313 from DocumentWindow.cpp

according to valgrind.
can’t see something suspicious there, but deactivating the buttons

DocumentWindow(T("BenennMich"), Colour(0xffffffff), NULL, true)
get’s rid of the write error.

also using the amalgamated version works too.
no write error there.

cleaning an rebuilding my juce lib. didn’t help either

next i’ll try to find out the differences…

comboy

3

Ooh, nasty. That looks like an extremely subtle c++ mistake, probably caused by the fact that I’ve embedded the proxy object in another object but am using it in a virtual way. The problem’s probably compiler-dependent.

I wrote that code a long time ago, and it’s certainly not how I’d have done it now, so I’ve re-written it properly - it’s checked in now if you want to have a go…

4

hmmm after the update i have no more write errors on creation,
but moving the mouse over one of the title bar buttons (minimise etc)
causes a immidiate segfault. (only happens in document window.
i have an DialogWindow where the close button works fine.

juce demo is still working
as well as my own application when build with the amalgamated version.

from the debugger:

in Button::sendStateMessage()

is called. at this point in the debugger the this pointer is valid.

next function it takes me is
juce_lookAndFeel.cpp

const MouseCursor LookAndFeel::getMouseCursorFor (Component& component)
{
    return component.getMouseCursor();
}

here the segfault occurs.
edit: Valgrind states the use of an uninitialised value followed by an invalid read of size 4 at return component.getMouseCursor();
strange thing is the this pointer has the same value as in Button::sendStateMessage(), although a valid value it seems wrong.
it’s times like these i miss the M$ debugger :wink:

comboy

5

Very very odd… Can’t see any obvious mistakes though. Hmm.

6

i can’t find a failure either…
release build without amalgamated works too!
only the debug build is affected.
i’ll havea closer look at the compiler flags in the premake.
really strange…

comboy

7

I’d hard time debugging this too. Your software needing to add this to the compiler CXXFLAGS:
-D"DEBUG=1" -D"_DEBUG=1" -D"LINUX=1"
(If you don’t add =1 it fails. You need both DEBUG and _DEBUG too).