U++ forum: Welcome to the forum

Search on this site

Search in forums

Home » U++ TheIDE » U++ TheIDE: Compiling, Linking, Debugging of your packages » Linux .brc handling bug

Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend

Linux .brc handling bug [message #6396]

Fri, 10 November 2006 14:13

zsolt
Messages: 697
Registered: December 2005
Location: Budapest, Hungary

Contributor

I get "Segmentation fault" when trying to access a binary resource.
I gess that binary resources are compiling into code area and operating system does not allow access to it or the pointer points to a wrong address.

I tried reference/brc as well and it has this problem also.
Debugger stops at memcpy int the next method:

dword MemStream::_Get(void *data, dword size) {
	if(size > (dword)(uintptr_t)(rdlim - ptr))
		size = rdlim - ptr;
	memcpy(data, ptr, size);
	ptr += size;
	return size;
}

Report message to a moderator

Re: Linux .brc handling bug [message #6417 is a reply to message #6396]

Sat, 11 November 2006 13:42

mirek
Messages: 13975
Registered: November 2005

Ultimate Member

Strange, just tested, reference/brc seems to work in ubuntu/64.

Platform?

Mirek

Report message to a moderator

Re: Linux .brc handling bug [message #6419 is a reply to message #6417]

Sat, 11 November 2006 15:02

zsolt
Messages: 697
Registered: December 2005
Location: Budapest, Hungary

Contributor

Ubuntu 606 32 bit.
I tried with different gcc versions (3.3, 3.4 and 4.0) but the result is the same.
gets segfault in memcpy()

Output is:
brc length: 99
cpp length: 1166
all count: 2
Segmentation fault

I will try it on my desktop machine with a newly installed U++ soon. Maybe my hacked TheIDE is the source of the problem.

Report message to a moderator

Re: Linux .brc handling bug [message #6420 is a reply to message #6419]

Sat, 11 November 2006 15:36

zsolt
Messages: 697
Registered: December 2005
Location: Budapest, Hungary

Contributor

I have tried upp-605 (downloaded binary from sf) and the problem is the same: reference/brc segfaults.

Ubuntu 606 32 bit, Intel PIV, 32 bit.

Report message to a moderator

Re: Linux .brc handling bug [message #7249 is a reply to message #6420]

Tue, 19 December 2006 14:13

zsolt
Messages: 697
Registered: December 2005
Location: Budapest, Hungary

Contributor

Can somebody help me in finding my bug with .brc handling?
I created a small app, loading and displaying main.cpp as brc.
It is working on Windows, but not on Linux (Ubuntu 606, 32 bit).
I have attached the testcase sources.

Attachment: BrcTest.zip
(Size: 1.51KB, Downloaded 286 times)

Report message to a moderator

Re: Linux .brc handling bug [message #7251 is a reply to message #7249]

Tue, 19 December 2006 15:37

Balage
Messages: 17
Registered: December 2006

Promising Member

Another example, that pointers and arrays ARE NOT THE SAME THING!

Modify the macro BINARY in Defs.h to:

#define BINARY(i, f) \
extern "C" char i[]; \
extern "C" int COMBINE(i, _length);

[Updated on: Tue, 19 December 2006 15:38]

Report message to a moderator

Re: Linux .brc handling bug [message #7259 is a reply to message #7251]

Tue, 19 December 2006 18:41

zsolt
Messages: 697
Registered: December 2005
Location: Budapest, Hungary

Contributor

Thanks, you showd me, where is the problem, but I changed my source instead of the upp header.

The correct line would be:

String s((const char*)&std_tmpl_main, std_tmpl_main_length);

The very "good" feature of msc is that it masks the problems and solves them silently.

Report message to a moderator

Re: Linux .brc handling bug [message #7260 is a reply to message #6396]

Tue, 19 December 2006 19:23

Balage
Messages: 17
Registered: December 2006

Promising Member

And that works? It shouldn't Confused

Taking the address of a char* results in char**, which you convert to const char*. It's only blind luck or coincidence I suppose why that doesn't crash big Smile

EDIT: After reading the C FAQ, the reason why that doesn't crash, is that you take the address of a variable which holds a pointer, namely the address of std_tmpl_main[0].

This part of the library is awfully messy.

I've found someone else who also had this problem: http://cprogrammers.blogspot.com/2006/10/c-programming-diffe rent-signature.html

EDIT: I took a look at the C FAQ, and the exact problem is mentioned there (a VERY GOOD read): http://c-faq.com/aryptr/index.html

So I recommend to DON'T use the above code, but instead, use what produced the segfault, and fix the library.

[Updated on: Tue, 19 December 2006 20:12]

Report message to a moderator

Re: Linux .brc handling bug [message #7261 is a reply to message #7260]

Tue, 19 December 2006 20:56

zsolt
Messages: 697
Registered: December 2005
Location: Budapest, Hungary

Contributor

Thanks for your help, now I undestand it better. I don't feel myself a C coder, so I didn't assume that the bug is the library.
Maybe BINARY_ARRAY and BINARY_MASK has the same problem.
I will ask Mirek about this whole thing.

Report message to a moderator

Re: Linux .brc handling bug [message #7262 is a reply to message #7261]

Tue, 19 December 2006 21:26

mirek
Messages: 13975
Registered: November 2005

Ultimate Member

I am afraid it can be more tricky... (because in Win32 the .obj is generated directly from data). brc is not my creation, I will rather contact the author

Report message to a moderator

Re: Linux .brc handling bug [message #7268 is a reply to message #6396]

Tue, 19 December 2006 22:36

Balage
Messages: 17
Registered: December 2006

Promising Member

That would be a good thing.

Generating the .obj directly? Why? The linux solution (if the externs are used correctly) works just as good on windows.

Report message to a moderator

Re: Linux .brc handling bug [message #7272 is a reply to message #7268]

Tue, 19 December 2006 23:36

mirek
Messages: 13975
Registered: November 2005

Ultimate Member

Balage wrote on Tue, 19 December 2006 16:36

That would be a good thing.

Generating the .obj directly? Why? The linux solution (if the externs are used correctly) works just as good on windows.

Because we can? Smile

Well, Tom's COFF library is in anyway (because of .dlls), so using it for this was natural things to do at the time.

Mirek

Report message to a moderator

Re: Linux .brc handling bug [message #7276 is a reply to message #6396]

Wed, 20 December 2006 00:06

Balage
Messages: 17
Registered: December 2006

Promising Member

BINARY_MASK is also dangerous.

#define BINARY_MASK(i, m) \
extern "C" byte *i[]; \
extern "C" int COMBINE(i, _length)[]; \
extern "C" int COMBINE(i, _count); \
extern "C" char *COMBINE(i, _files)[];

The xxx_files part is generated like this:

char *xxx_files[] = {
	"File1.cpp",
	"File2.cpp",
};

That's an array of pointers, pointing to string literals. And string literals are const. So trying to modify xxx_files[i][n] also segfaults.

The solution is to either:
- Modify type to this: const char* xxx_files[]
(This also means to modify BINARY_MASK macro)

Or:
- Generate an array for each filename, then add those to xxx_files, like this:

static char xxx_file_1[] = "File1.cpp";

static char xxx_file_2[] = "File2.cpp";

char *xxx_files[] = {
	xxx_file_1,
	xxx_file_2,
};

Anyway, I also think that byte should be replaced with char, as that's what is used for the definition.

The current fix:

#define BINARY(i, f) \
extern "C" char i[]; \
extern "C" int COMBINE(i, _length);

#define BINARY_ARRAY(i, x, f) \
extern "C" char *i[]; \
extern "C" int COMBINE(i, _length)[]; \
extern "C" int COMBINE(i, _count);

#define BINARY_MASK(i, m) \
extern "C" char *i[]; \
extern "C" int COMBINE(i, _length)[]; \
extern "C" int COMBINE(i, _count); \
extern "C" const char *COMBINE(i, _files)[];

This makes types correct, so you don't accidentally segfault.

[Updated on: Wed, 20 December 2006 00:16]

Report message to a moderator

Previous Topic:	Compile problem in Gentoo-AMD64
Next Topic:	Can't Seem to See Console Output While In the Debugger

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Sat May 04 08:13:28 CEST 2024

Total time taken to generate the page: 0.02362 seconds