Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » U++ TheIDE » U++ TheIDE: Other Features Wishlist and/or Bugs » bug in latest svn
bug in latest svn [message #15618] Thu, 01 May 2008 15:35 Go to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
Opening a package with latest svn219 brings a invalid memory access error. That doesn't happen on svn218 previous release.

Ciao

Max

EDIT : The bad stuff is that bug appears only on optimal build, and not in debug mode....

Max

[Updated on: Thu, 01 May 2008 15:52]

Report message to a moderator

Re: bug in latest svn [message #15622 is a reply to message #15618] Thu, 01 May 2008 19:52 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1358
Registered: December 2006
Ultimate Contributor
mdelfede wrote on Thu, 01 May 2008 09:35

Opening a package with latest svn219 brings a invalid memory access error. That doesn't happen on svn218 previous release.



In case of TheIDE + NOGTK I couldn't see any problem with opening a package.


Regards,
Novo
Re: bug in latest svn [message #15624 is a reply to message #15622] Thu, 01 May 2008 20:01 Go to previous messageGo to next message
bytefield is currently offline  bytefield
Messages: 210
Registered: December 2007
Experienced Member
Well, it's not happen always, just some times. I use SVN.219 and meet this problem just once.
Edit: Maybe with NOGTK flag, the build is free of.


cdabbd745f1234c2751ee1f932d1dd75

[Updated on: Thu, 01 May 2008 20:03]

Report message to a moderator

Re: bug in latest svn [message #15626 is a reply to message #15624] Thu, 01 May 2008 20:45 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
Well, for me it happens on every package opened...

Max
Re: bug in latest svn [message #15628 is a reply to message #15626] Thu, 01 May 2008 21:10 Go to previous messageGo to next message
bytefield is currently offline  bytefield
Messages: 210
Registered: December 2007
Experienced Member
Maybe it's a 64 bits issue? Which version have you tried? Both?

cdabbd745f1234c2751ee1f932d1dd75
Re: bug in latest svn [message #15632 is a reply to message #15628] Thu, 01 May 2008 22:31 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1358
Registered: December 2006
Ultimate Contributor
bytefield wrote on Thu, 01 May 2008 15:10

Maybe it's a 64 bits issue? Which version have you tried? Both?


I'm using x86_64.
I'll try to run valgrind on TheIDE and check for possible problems.


Regards,
Novo
Re: bug in latest svn [message #15634 is a reply to message #15632] Thu, 01 May 2008 23:00 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
I'm using 64 bit too
Re: bug in latest svn [message #15638 is a reply to message #15632] Thu, 01 May 2008 23:28 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1358
Registered: December 2006
Ultimate Contributor
Novo wrote on Thu, 01 May 2008 16:31

bytefield wrote on Thu, 01 May 2008 15:10

Maybe it's a 64 bits issue? Which version have you tried? Both?


I'm using x86_64.
I'll try to run valgrind on TheIDE and check for possible problems.


I see approximately a thousand messages “Conditional jump or move depends on uninitialised value(s)” and a lot of “Use of uninitialised value of size 8”.

That can be a problem. I can check that with debug build of TheIDE.


Regards,
Novo
Re: bug in latest svn [message #15640 is a reply to message #15638] Thu, 01 May 2008 23:51 Go to previous messageGo to next message
bytefield is currently offline  bytefield
Messages: 210
Registered: December 2007
Experienced Member
OK, until now seems that just 64 bits build is affected.
Other users of 32 bits build? (Not me Smile , if I remember well I've got such an error but don't know if with SVN.219 ).
For me it work normal, without errors.


cdabbd745f1234c2751ee1f932d1dd75
Re: bug in latest svn [message #15641 is a reply to message #15638] Fri, 02 May 2008 00:15 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1358
Registered: December 2006
Ultimate Contributor
Novo wrote on Thu, 01 May 2008 17:28

Novo wrote on Thu, 01 May 2008 16:31

bytefield wrote on Thu, 01 May 2008 15:10

Maybe it's a 64 bits issue? Which version have you tried? Both?


I'm using x86_64.
I'll try to run valgrind on TheIDE and check for possible problems.


I see approximately a thousand messages “Conditional jump or move depends on uninitialised value(s)” and a lot of “Use of uninitialised value of size 8”.

That can be a problem. I can check that with debug build of TheIDE.



A lot of that:

==31285== Conditional jump or move depends on uninitialised value(s)
==31285==    at 0x5919DB: Upp::CodeEditor::SyntaxState::ScanSyntax(unsigned short const*, unsigned short co
==31285==    by 0x5964E6: Upp::CodeEditor::ScanSyntax(int) (in /export/home/ssikorsk/dvlp/upp/svn/upp/out/G
==31285==    by 0x598E2C: Upp::CodeEditor::HighlightLine(int, Upp::Vector<Upp::LineEdit::Highlight>&, int)
==31285==    by 0x5E1F34: Upp::LineEdit::Paint0(Upp::Draw&) (in /export/home/ssikorsk/dvlp/upp/svn/upp/out/
==31285==    by 0x5E2A68: Upp::LineEdit::Paint(Upp::Draw&) (in /export/home/ssikorsk/dvlp/upp/svn/upp/out/G
==31285==    by 0x83ECEC: Upp::Ctrl::PaintOpaqueAreas(Upp::Draw&, Upp::Rect_<int> const&, Upp::Rect_<int> c
==31285==    by 0x83E949: Upp::Ctrl::PaintOpaqueAreas(Upp::Draw&, Upp::Rect_<int> const&, Upp::Rect_<int> c
==31285==    by 0x83E949: Upp::Ctrl::PaintOpaqueAreas(Upp::Draw&, Upp::Rect_<int> const&, Upp::Rect_<int> c
==31285==    by 0x83E949: Upp::Ctrl::PaintOpaqueAreas(Upp::Draw&, Upp::Rect_<int> const&, Upp::Rect_<int> c
==31285==    by 0x83E949: Upp::Ctrl::PaintOpaqueAreas(Upp::Draw&, Upp::Rect_<int> const&, Upp::Rect_<int> c
==31285==    by 0x83E949: Upp::Ctrl::PaintOpaqueAreas(Upp::Draw&, Upp::Rect_<int> const&, Upp::Rect_<int> c
==31285==    by 0x83E949: Upp::Ctrl::PaintOpaqueAreas(Upp::Draw&, Upp::Rect_<int> const&, Upp::Rect_<int> c
==31285==



==31285== Conditional jump or move depends on uninitialised value(s)
==31285==    at 0x84ABCB: Upp::Ctrl::Refresh() (in /export/home/ssikorsk/dvlp/upp/svn/upp/out/GCC.Debug.Gui
==31285==    by 0x632597: Upp::ArrayCtrl::Sort(Upp::ArrayCtrl::Order const&) (in /export/home/ssikorsk/dvlp
==31285==    by 0x6325DF: Upp::ArrayCtrl::Sort(int, int (*)(Upp::Value const&, Upp::Value const&)) (in /exp
==31285==    by 0x5559DA: Upp::ArrayCtrl::Sort() (in /export/home/ssikorsk/dvlp/upp/svn/upp/out/GCC.Debug.G
==31285==    by 0x566552: Browser::Reload() (in /export/home/ssikorsk/dvlp/upp/svn/upp/out/GCC.Debug.Gui.No
==31285==    by 0x571687: Browser::Browser() (in /export/home/ssikorsk/dvlp/upp/svn/upp/out/GCC.Debug.Gui.N
==31285==    by 0x45C366: Ide::Ide() (in /export/home/ssikorsk/dvlp/upp/svn/upp/out/GCC.Debug.Gui.Nogtk.Sha
==31285==    by 0x482D70: GuiMainFn_() (in /export/home/ssikorsk/dvlp/upp/svn/upp/out/GCC.Debug.Gui.Nogtk.S
==31285==    by 0x484155: main (in /export/home/ssikorsk/dvlp/upp/svn/upp/out/GCC.Debug.Gui.Nogtk.Shared/id


==31285== Conditional jump or move depends on uninitialised value(s)
==31285==    at 0x5C7C22: Upp::LineEdit::Layout() (in /export/home/ssikorsk/dvlp/upp/svn/upp/out/GCC.Debug.
==31285==    by 0x5C407D: Upp::LineEdit::SetFont(Upp::Font) (in /export/home/ssikorsk/dvlp/upp/svn/upp/out/
==31285==    by 0x592D51: Upp::CodeEditor::CodeEditor() (in /export/home/ssikorsk/dvlp/upp/svn/upp/out/GCC.
==31285==    by 0x43089D: AssistEditor::AssistEditor() (in /export/home/ssikorsk/dvlp/upp/svn/upp/out/GCC.D
==31285==    by 0x45C2A8: Ide::Ide() (in /export/home/ssikorsk/dvlp/upp/svn/upp/out/GCC.Debug.Gui.Nogtk.Sha
==31285==    by 0x482D70: GuiMainFn_() (in /export/home/ssikorsk/dvlp/upp/svn/upp/out/GCC.Debug.Gui.Nogtk.S
==31285==    by 0x484155: main (in /export/home/ssikorsk/dvlp/upp/svn/upp/out/GCC.Debug.Gui.Nogtk.Shared/id
==31285==
==31285== Conditional jump or move depends on uninitialised value(s)
==31285==    at 0x5C3040: Upp::LineEdit::SetHBar() (in /export/home/ssikorsk/dvlp/upp/svn/upp/out/GCC.Debug
==31285==    by 0x5C7C7E: Upp::LineEdit::Layout() (in /export/home/ssikorsk/dvlp/upp/svn/upp/out/GCC.Debug.
==31285==    by 0x5C407D: Upp::LineEdit::SetFont(Upp::Font) (in /export/home/ssikorsk/dvlp/upp/svn/upp/out/
==31285==    by 0x592D51: Upp::CodeEditor::CodeEditor() (in /export/home/ssikorsk/dvlp/upp/svn/upp/out/GCC.
==31285==    by 0x43089D: AssistEditor::AssistEditor() (in /export/home/ssikorsk/dvlp/upp/svn/upp/out/GCC.D
==31285==    by 0x45C2A8: Ide::Ide() (in /export/home/ssikorsk/dvlp/upp/svn/upp/out/GCC.Debug.Gui.Nogtk.Sha
==31285==    by 0x482D70: GuiMainFn_() (in /export/home/ssikorsk/dvlp/upp/svn/upp/out/GCC.Debug.Gui.Nogtk.S
==31285==    by 0x484155: main (in /export/home/ssikorsk/dvlp/upp/svn/upp/out/GCC.Debug.Gui.Nogtk.Shared/id


It looks like there is no "Use of uninitialised value of size 8" in debug build.

Probably, a version of GCC is important too ...


Regards,
Novo
Re: bug in latest svn [message #15642 is a reply to message #15640] Fri, 02 May 2008 00:16 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
UPDATE :

The error is the same compiling previous svn versions... on ubuntu hardy. As previous deb builds were made on ubuntu gutsy, I guess that's some problem compiling upp on hardy.

So, GCC 4.2.3 and gnome 2.2.

Max
Re: bug in latest svn [message #15644 is a reply to message #15642] Fri, 02 May 2008 00:49 Go to previous messageGo to next message
bytefield is currently offline  bytefield
Messages: 210
Registered: December 2007
Experienced Member
I've rebuilt theide and getting "Invalid memory access" Mad
So the problem affect 32 bits build too. Last SVN.219 build was made on Ubuntu 7.10.


cdabbd745f1234c2751ee1f932d1dd75
Re: bug in latest svn [message #15645 is a reply to message #15644] Fri, 02 May 2008 00:55 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
Error happens on Core/Heap.cpp, line 311 :

m.list = l->next;

in function MemoryAllocSz(). Removing the smart allocation stuff for small sizes theide runs, but again memory error on exit.
So, I think something is breaking memory pool somewhere... quite difficult to locate.
Next error (removing smart allocation...) happens in file Core/LHeap.cpp, line 29, Unlink() function. That shows that pointers are garbaged

Max

[Updated on: Fri, 02 May 2008 00:57]

Report message to a moderator

Re: bug in latest svn [message #15646 is a reply to message #15644] Fri, 02 May 2008 01:04 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1358
Registered: December 2006
Ultimate Contributor
bytefield wrote on Thu, 01 May 2008 18:49

I've rebuilt theide and getting "Invalid memory access" Mad
So the problem affect 32 bits build too. Last SVN.219 build was made on Ubuntu 7.10.


I'm using pretty old SuSe. GCC version 4.0.1. libc version 2.3.5 (20050720)

Rolling Eyes


Regards,
Novo
Re: bug in latest svn [message #15653 is a reply to message #15646] Fri, 02 May 2008 09:44 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
Novo wrote on Fri, 02 May 2008 01:04

bytefield wrote on Thu, 01 May 2008 18:49

I've rebuilt theide and getting "Invalid memory access" Mad
So the problem affect 32 bits build too. Last SVN.219 build was made on Ubuntu 7.10.


I'm using pretty old SuSe. GCC version 4.0.1. libc version 2.3.5 (20050720)

Rolling Eyes


So it must be a gcc/libc/gnome version stuff.
BTW, If you compile it in release/optimal mode BUT enabling full debug, it still present the problem but it becomes debuggable....
But I still think that'll not an easy bug to find Sad

Max

EDIT : Enabling DEBUG in Heap.cpp theide stops with "writes to freed blocks detected" error... maybe an hint ?

[Updated on: Fri, 02 May 2008 09:48]

Report message to a moderator

Re: bug in latest svn [message #15662 is a reply to message #15653] Fri, 02 May 2008 22:15 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1358
Registered: December 2006
Ultimate Contributor
I’ve already found returning reference to a temporary object and a bunch of uninitialized class members.

That can cause application to crash, especially when you change version of compiler.

Hopefully, I’ll submit a patch at the end of the day.


Regards,
Novo

[Updated on: Fri, 02 May 2008 23:37]

Report message to a moderator

Re: bug in latest svn [message #15663 is a reply to message #15662] Fri, 02 May 2008 23:45 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
Novo wrote on Fri, 02 May 2008 22:15

I’ve already found returning reference to a temporary object and a bunch of uninitialized class members.

That can cause application to crash, especially when you change version of compiler.

Hopefully, I’ll submit a patch at the end of the day.



Interesting ! I'm trying to locate the bug, but with no success up to now...

Max

Well, just a new finding... The error seems not depend on optimization, but only on DEBUG flag... if you compile in release mode (DEBUG flag undefined), with or without debugging info, the bug is there. If you manually enable DEBUG flag, the bug disappears. maybe the bug is in memory allocation routines, which are different on DEBUG flag.

[Updated on: Sat, 03 May 2008 00:53]

Report message to a moderator

Re: bug in latest svn [message #15667 is a reply to message #15662] Sat, 03 May 2008 17:42 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1358
Registered: December 2006
Ultimate Contributor
Novo wrote on Fri, 02 May 2008 16:15


Hopefully, I’ll submit a patch at the end of the day.



Sorry, couldn't keep my promice.

I probably miss something, but code below always was a problem.

const String& GetCppFile(int i)
{
	INTERLOCKED_(cpp_file_mutex) {
		return cpp_file[i];
	}
	return String();
}


Should be something like that:

const String& GetCppFile(int i)
{
	INTERLOCKED_(cpp_file_mutex) {
		return cpp_file[i];
	}

        static String value;
	return value;
}



I'm not sure about thread-safety of static variable initialization though.


Regards,
Novo

[Updated on: Sat, 03 May 2008 17:43]

Report message to a moderator

Re: bug in latest svn [message #15668 is a reply to message #15667] Sat, 03 May 2008 19:17 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
Novo wrote on Sat, 03 May 2008 17:42

Novo wrote on Fri, 02 May 2008 16:15


Hopefully, I’ll submit a patch at the end of the day.



Sorry, couldn't keep my promice.

I probably miss something, but code below always was a problem.

const String& GetCppFile(int i)
{
	INTERLOCKED_(cpp_file_mutex) {
		return cpp_file[i];
	}
	return String();
}


Should be something like that:

const String& GetCppFile(int i)
{
	INTERLOCKED_(cpp_file_mutex) {
		return cpp_file[i];
	}

        static String value;
	return value;
}



I'm not sure about thread-safety of static variable initialization though.



AFAIK that's a right behaviour, as returned temporary string is firs assigned to result and then deleted. With static variables you loose reentrancy (usually).

BTW, after long debugging I couldn't locate the problem....

Max

Re: bug in latest svn [message #15670 is a reply to message #15668] Sun, 04 May 2008 00:07 Go to previous messageGo to previous message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
Well.... found at least a dirty workaround.

In 'heap.cpp', line 148 :
//#ifdef _DEBUG
#if 1 // @@@@@ WORKAROUND !!!!!
void FreeFill(dword *ptr, int count)
{
	while(count--)
		*ptr++ = 0x65657246;
}

void FreeCheck(dword *ptr, int count)
{
	int c = count;
	while(c--)
		if(*ptr++ != 0x65657246)
			HeapPanic("Writes to freed blocks detected", ptr, sizeof(dword) * count);
}

#endif


And, (that's the real workaround....), in file String.cpp, line 22 :

static inline void MFree_S(void *ptr)
{
	MCache& m = mcache[1];
	((FreeLink *)ptr)->next = m.list;
	m.list = (FreeLink *)ptr;
//#ifdef _DEBUG
#if 1 // @@@@ WORKAROUND !!!!!
#ifdef CPU_64
	FreeFill((dword *)ptr + 2, 32 / 4 - 2);
#else
	FreeFill((dword *)ptr + 1, 32 / 4 - 1);
#endif
#endif
	if(++m.count > CACHEMAX)
		MFree_Reduce(m, 1);
}


This 'hides' the bug, but I guess it's still there.
Theide run fine, and also my (few) test apps.

For Mirek : the bug should be OR in string functions, OR in Vector stuff, in particular in VectorGrow stuffs.

Here a small app that shows the behaviour....BUT, to test it you have to :
1) Build in Optimal mode (NO DEBUG flag set)
2) Change optimal mode debug flag to -O0 (otherwise it's undebuggable because of optimizations...)
3) Enable full debug info even in optimal mode
4) Enable DEBUG just in heap.cpp, and change allocation stuffs to the debugger ones (some changes in core.h, heapdbg.cpp and others...)
5) The hard stuff... the bug arises before main(), so you've got to disable some initialization stuffs (quite long work). If not, you'll have to follow some hundreds of calls before main().

After point 5 done, the app will execute the first loop, then show the error. Following this, you'll find mostly string and vectormap calls. Quite long to follow, yet, but better than debugging theide Smile
I stopped here because your string stuffs are quite un-understandable (and uncommented....).
Here the test app :
#include <Core/Core.h>

using namespace Upp;

CONSOLE_APP_MAIN
{
	char key[200];
	
	VectorMap<String, char *> aMap;
	
	int nKeys = 100;
	
	for(int i = 0; i < nKeys; i++)
	{
		sprintf(key, "Chiave di prova n.%d", i);
		RLOG("\n\n================================================================\nAdding key " << key);
		RLOG("AllocTest before....");
//		AllocTest();
		aMap.Add(key);
		RLOG("Key added, AllocTest after");
//		AllocTest();
	}
	
	exit(0);
}

Commented AllocTest() stuffs are from this routine :
void AllocTest(void)
{
	RLOG("AllocTest -- Entering");
	const int numAllocs = 100;
	size_t sizeAlloc = 32;
	
	void *p[numAllocs];
	for(int i = 0; i < numAllocs; i++)
		p[i] = MemoryAllocSz(sizeAlloc);
	RLOG("AllocTest -- Memory allocated");
	for(int i = 0; i < numAllocs; i++)
		MemoryFree(p[i]);
	RLOG("AllocTest -- Memory freed");
	
}


These just do some dummy alloc/frees to trigger the bug.

BTW... I've got a suggestion here... just to ease the debugging.
I guess we should have alternate memory allocation stuffs that could be used (independently from DEBUG flag) to check the heap on demand. MemoryCheck() and memoryCheckDebug() doesn't do the job, even when enabled by hand. And, the best would be to have a switchable pointer-checking functions for all Upp containers, called entering and leaving each container's method.
All that could be switched by a CHECKPOINTERS macro, and should check container's internal pointers and free heap.

Another 'stylish' stuff... many functions that resides in heap.cpp should (IMHO) belong to heapdbg.cpp.

Ciao

Max


Well, after some tests on 32 bit (thanks Bytefield), I've seen that workarount don't work for 32 bit builds... so, better to stay on SVN 219 build (for 32 bit) and SVN218 build (for 64) up to the stuff is fixed.

Max

[Updated on: Sun, 04 May 2008 12:19]

Report message to a moderator

Previous Topic: Some lack of features
Next Topic: [BUG] Ide loses "maximized" setting on minimize
Goto Forum:
  


Current Time: Thu Mar 28 18:15:47 CET 2024

Total time taken to generate the page: 0.01357 seconds