Home » Developing U++ » Mac OS » MacOS X woes
|
|
| Re: MacOS X woes [message #7139 is a reply to message #7137] |
Fri, 15 December 2006 14:07   |
lundman
Messages: 175
Registered: March 2006
Location: Tokyo
|
Experienced Member |
|
|
I'm not so good at your debug code, but gdb I can handle... just doing a quick run through of the UnpackImlData() function, what should "len" normally be? I would guess this number is large:
(First pass, first image)
(gdb) p ib
$9 = {
<NoCopy> = {<No data fields>},
members of ImageBuffer:
kind = 0,
size = {
<Moveable<Size_<int>,EmptyClass>> = {
<> = {<No data fields>}, <No data fields>},
members of Size_<int>:
cx = 3328,
cy = 3328
},
pixels = {
<Moveable<Buffer<RGBA>,EmptyClass>> = {
<> = {<No data fields>}, <No data fields>},
members of Buffer<RGBA>:
ptr = 0x428a008
},
hotspot = {
<Moveable<Point_<int>,EmptyClass>> = {
<> = {<No data fields>}, <No data fields>},
members of Point_<int>:
x = 256,
y = 256
},
[snip]
(gdb) n
240 s += 13;
(gdb) n
241 int len = ib.GetLength();
(gdb) p len
$10 = 11075584
Am I getting warmer?
|
|
|
|
| Re: MacOS X woes [message #7140 is a reply to message #7139] |
Fri, 15 December 2006 14:10 |
lundman
Messages: 175
Registered: March 2006
Location: Tokyo
|
Experienced Member |
|
|
Actually, its just size.cx*size.cy and at 3328 pixels each, that is the right value. So assuming 3328x3328 is correct..
The function ends with, after just one pass:
255 return img;
(gdb) p img
$3 = {
<MoveableAndDeepCopyOption<Vector<Image>,EmptyClass>> = {
<Moveable<Vector<Image>,DeepCopyOption<Vector<Image>, EmptyClass> >> = {
<DeepCopyOption<Vector<Image>,EmptyClass>> = {
<> = {<No data fields>}, <No data fields>}, <No data fields>}, <No data fields>},
members of Vector<Image>:
vector = 0xbffff740,
items = -1,
alloc = 2315384
}
|
|
|
|
|
|
|
|
| Re: MacOS X woes [message #7155 is a reply to message #7142] |
Sat, 16 December 2006 02:30 |
lundman
Messages: 175
Registered: March 2006
Location: Tokyo
|
Experienced Member |
|
|
When I rsynced the new Util.h it over-wrote my port changing, including setting of flagPPC. Sigh.
Anyway, back to where we were, looking at the image editor segv.
Called LoadIml(), which does not find IMAGE_ID and IMAGE_DATA, so it throws the exception, and loads in a more low-level loader.
Seems to parse the input ok, until is reaches:
(gdb) p parser
$28 = (CParser &) @0xbffe5a70: {
term = 0x2161732 "IMAGE_SCAN(\"?\\377\\377\\377\\13????????????????????????????????\\377\\377\\377\")\nIMAGE_PACKED(ufxp, \"\\2\\20\\0\\0\\0\\20\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\")\nIMAGE_BEGIN(options)\n\tIMAGE_SCAN(\"?\\1vlV????\\1??m?\\2??s?"...,
100 else if(id == "IMAGE_PACKED" && parser.IsChar('\"'))
(gdb) n
105 StringStream ss(d);
(gdb) n
106 ss % image;
(gdb) n
107 if(!ss.IsError())
(gdb) n
108 accepted = true;
(gdb) n
109 }
(gdb) n
112 if(name.GetLength() >= 6 && !memcmp(name, "_java_", 6))
(gdb) p name
[snip]
ptr = 0x1b89654 "ufxp"
(gdb) n
115 if(accepted)
(gdb) n
117 if(name.GetLength() >= 4 && !memcmp(name, "im__", 4))
(gdb) n
120 Image m = RLEToAlpha(encoded_data, image.size);
(gdb) p encoded_data
$34 = {
<AString<char,String>> = {
<Moveable<String,EmptyClass>> = {
<> = {<No data fields>}, <No data fields>},
members of AString<char,String>:
ptr = 0x20c9414 "????\001?????????????????????\004????????????????\002??????????????\004???[[[?????????\003ooo??????????????\n???\036\036\036\033\033\033??????ooo\f\f\f\016\016\016???????????????\n999\001\001\001"
}, <No data fields>}
(gdb) p image.size
$35 = {
<Moveable<Size_<int>,EmptyClass>> = {
<> = {<No data fields>}, <No data fields>},
members of Size_<int>:
cx = 268435456,
cy = 268435456
}
Should sizes be set here? Before we call, or is it just uninitialised?
encoded_data looks correct, in that it was parsed in ok.
(gdb) x/16bx encoded_data.ptr
0x20c9414: 0x83 0xff 0xff 0xff 0x01 0xfd 0xfd 0xfd
0x20c941c: 0x82 0xfc 0xfc 0xfc 0x83 0xff 0xff 0xff
But it dies in RLEToAlpha.
Breakpoint 3, RLEToAlpha (rle=@0xbffe5898, sz=@0xbffe5850) at ImlFile.cpp:32
32 ImageBuffer ib(sz);
(gdb) p sz
$39 = (Size &) @0xbffe5850: {
<Moveable<Size_<int>,EmptyClass>> = {
<> = {<No data fields>}, <No data fields>},
members of Size_<int>:
cx = 268435456,
cy = 268435456
Makes me think the size should be "somewhat smaller".
You set the size at IMAGE_END phase, I don't recall it reading IMAGE_END. Could it be our .iml file is incorrect,old ?
Has IMAGE_BEGIN(ufxp)
IMAGE_SCAN x 16
IMAGE_PACKED(ufxp, ....)
Then next IMAGE_BEGIN. etc. (of two)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: MacOS X woes [message #7227 is a reply to message #7206] |
Tue, 19 December 2006 01:15 |
lundman
Messages: 175
Registered: March 2006
Location: Tokyo
|
Experienced Member |
|
|
Ah whoopsie.. I assumed you had previously done CPU_PPC to be powerpc, since the PocketPC cpu arch is ARM, SH3 or MIPS.
I will guess what is needed here and submit a patch.
I use something along the lines of:
#ifdef flagOSX11
#define PLATFORM_OSX11
#define PLATFORM_POSIX
#ifdef flagGUI
#define PLATFORM_X11
#endif
#ifdef flagTESTLEAKS
#define TESTLEAKS
#endif
// defines set by OsX for us.
#ifdef __POWERPC__
#define flagPOWERPC
#endif
#ifdef __i386__
#define flagX86
#endif
#endif
However, can you help to find a solution as to how to be able to do Intel build on a PPC platform and vv.
The problem is, I need to set "-arch i386", which currently I set in "Build Environment". This is only use for Compile, and not use in Linking. There are no Linking options that I can see in Build Environment. So without that set, "__i386__" is not set, so the linking is done as POWERPC.
If no extra input boxes in the GUI, how can I user-optionally build for different archs?
The sources specify "linkoptions" which is Gathered from pkg.link. Not sure where that comes from.
I could take out "flagOSX11" and make two flags, but that seems uneccessary when you have a fully features build environment setup.
Can I define a new GCC32 and supply different flags?
[Updated on: Tue, 19 December 2006 02:28] Report message to a moderator |
|
|
|
| Re: MacOS X woes [message #7280 is a reply to message #7227] |
Wed, 20 December 2006 04:13 |
lundman
Messages: 175
Registered: March 2006
Location: Tokyo
|
Experienced Member |
|
|
Fetched latest sources to try out the Serialization changes (20th GMT 01:00).
Lots of issues in Installer.cpp (path not defines etc) but I assume that is just work in progress, so //'ing my way through that. It didn't like "::" in "::GetLastError()" in Socket.cpp.
Anyway, loading "ide" I get:
Assertion failed in /Users/lundman/src/upp/uppsrc/Core/Stream.cpp, line 1362
!backup.IsError()
(gdb) bt
#0 0x9004796c in kill ()
#1 0x9012dc14 in abort ()
#2 0x00237abc in Upp::AssertFailed (file=0x3a68d0 "/Users/lundman/src/upp/uppsrc/Core/Stream.cpp", line=1362, cond=0x3a6c14 "!backup.IsError()") at Util.cpp:83
#3 0x002495fc in Upp::Load (serialize=@0xbffe6cb8, stream=@0xbffe6cc0) at Stream.cpp:1362
#4 0x0026ae5c in Upp::LoadFromFile (serialize=@0xbffe6d70, file=0x0) at Stream.cpp:1390
#5 0x00456624 in Upp::LoadFromFile<Ide> (x=@0xbffe6ee8, name=0x0) at Util.h:339
#6 0x00086bf0 in GuiMainFn_ () at idewin.cpp:805
#7 0x0008749c in main (argc=1, argv=0xbffffaec, envptr=0xbffffaf4) at idewin.cpp:571
That "name" and "file" are NULL probably is not good? But might be normal behavior for all I know.
Also, I'm in _awe_ of the size of your "ide" variable. I'm never doing "p ide" again.
|
|
|
|
|
|
| Re: MacOS X woes [message #7282 is a reply to message #7281] |
Wed, 20 December 2006 05:01 |
lundman
Messages: 175
Registered: March 2006
Location: Tokyo
|
Experienced Member |
|
|
D'oh, you should have said I need to delete my .ide/ config files since they are all big-endian 
However, we do get this situation:
rm .ide/ide.cfg
gdb ide
(gdb) run
(Once loaded, click Cancel instead of Selection a main Package)
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x1876d580
0x00275584 in Upp::RichEdit::SetupRuler (this=0xbfff707c) at Editor.cpp:272
272 zoom, q.grid, q.numbers, q.numbermul, q.marks);
(gdb) p unit
$1 = 16777216
And indeed, now that it has written "ide.cfg" it won't load it unless I delete it first, with the exact same core. So for some reason "unit" ends up big-endian in memory (as well as on disk?) even when Initialised from scratch.
[Updated on: Wed, 20 December 2006 05:02] Report message to a moderator |
|
|
|
|
|
| Re: MacOS X woes [message #7284 is a reply to message #7227] |
Wed, 20 December 2006 08:57 |
 |
mirek
Messages: 14290
Registered: November 2005
|
Ultimate Member |
|
|
| lundman wrote on Mon, 18 December 2006 19:15 |
Ah whoopsie.. I assumed you had previously done CPU_PPC to be powerpc, since the PocketPC cpu arch is ARM, SH3 or MIPS.
I will guess what is needed here and submit a patch.
I use something along the lines of:
|
OK, now at the beginning of Core.h.
Mirek
[Updated on: Wed, 20 December 2006 08:58] Report message to a moderator |
|
|
|
| Re: MacOS X woes [message #7285 is a reply to message #7283] |
Wed, 20 December 2006 09:14 |
lundman
Messages: 175
Registered: March 2006
Location: Tokyo
|
Experienced Member |
|
|
Right
Breakpoint 1, Upp::RichEdit::SerializeSettings (this=0xbfff707c, s=@0xbffe6c20) at /Users/lundman/src/upp/uppsrc/RichEdit/Editor.cpp:453
453 int version = 1;
(gdb) s
454 s / version;
(gdb) s
Upp::Stream::operator/ (this=0xbffe6c20, i=@0xbffe69b8) at Stream.h:223
223 Stream& operator/(int& i) { dword w = i + 1; Pack(w); i = w - 1; return *this; }
(gdb) s
Upp::Stream::Pack (this=0xbffe6c20, w=@0xbffe6958) at /Users/lundman/src/upp/uppsrc/Core/Stream.cpp:471
471 if(IsError()) return;
(gdb) n
491 }
(gdb) n
0x0041d410 in Upp::Stream::operator/ (this=0xbffe6c20, i=@0xbffe69b8) at Stream.h:223
223 Stream& operator/(int& i) { dword w = i + 1; Pack(w); i = w - 1; return *this; }
(gdb) n
Upp::RichEdit::SerializeSettings (this=0xbfff707c, s=@0xbffe6c20) at /Users/lundman/src/upp/uppsrc/RichEdit/Editor.cpp:455
455 s % unit;
(gdb) p version
$4 = 1
(gdb) p unit
$5 = 1
(gdb) s
Upp::Stream::operator% (this=0xbffe6c20, d=@0xbfffb67c) at /Users/lundman/src/upp/uppsrc/Core/Stream.cpp:585
585 SerializeRaw((dword *)&d, 1);
(gdb) s
Upp::Stream::SerializeRaw (this=0xbffe6c20, data=0xbfffb67c, count=1) at /Users/lundman/src/upp/uppsrc/Core/Stream.cpp:457
457 SerializeRaw((byte *)data, 4 * count);
(gdb) s
Upp::Stream::SerializeRaw (this=0xbffe6c20, data=0xbfffb67c "", size=4) at /Users/lundman/src/upp/uppsrc/Core/Stream.cpp:442
442 if(IsError()) return;
(gdb) n
447 }
(gdb) n
Upp::Stream::SerializeRaw (this=0xbffe6c20, data=0xbfffb67c, count=1) at /Users/lundman/src/upp/uppsrc/Core/Stream.cpp:459
459 EndianSwap(data, count);
(gdb) p data
$6 = (dword *) 0xbfffb67c
(gdb) p *data
$7 = 1
(gdb) n
461 }
(gdb) p *data
$8 = 16777216
(gdb) n
Upp::Stream::operator% (this=0xbffe6c20, d=@0xbfffb67c) at /Users/lundman/src/upp/uppsrc/Core/Stream.cpp:586
586 return *this;
(gdb)
587 }
(gdb)
Upp::RichEdit::SerializeSettings (this=0xbfff707c, s=@0xbffe6c20) at /Users/lundman/src/upp/uppsrc/RichEdit/Editor.cpp:456
456 s % showcodes;
(gdb) p unit
$9 = 16777216
Seems it is given a default value, then gets EndianSwapped, when maybe it should only be endianswapped when read?
|
|
|
|
| Re: MacOS X woes [message #7286 is a reply to message #7285] |
Wed, 20 December 2006 09:29 |
|
mirek
Messages: 14290
Registered: November 2005
|
Ultimate Member |
|
|
| lundman wrote on Wed, 20 December 2006 03:14 |
Right
Breakpoint 1, Upp::RichEdit::SerializeSettings (this=0xbfff707c, s=@0xbffe6c20) at /Users/lundman/src/upp/uppsrc/RichEdit/Editor.cpp:453
453 int version = 1;
(gdb) s
454 s / version;
(gdb) s
Upp::Stream::operator/ (this=0xbffe6c20, i=@0xbffe69b8) at Stream.h:223
223 Stream& operator/(int& i) { dword w = i + 1; Pack(w); i = w - 1; return *this; }
(gdb) s
Upp::Stream::Pack (this=0xbffe6c20, w=@0xbffe6958) at /Users/lundman/src/upp/uppsrc/Core/Stream.cpp:471
471 if(IsError()) return;
(gdb) n
491 }
(gdb) n
0x0041d410 in Upp::Stream::operator/ (this=0xbffe6c20, i=@0xbffe69b8) at Stream.h:223
223 Stream& operator/(int& i) { dword w = i + 1; Pack(w); i = w - 1; return *this; }
(gdb) n
Upp::RichEdit::SerializeSettings (this=0xbfff707c, s=@0xbffe6c20) at /Users/lundman/src/upp/uppsrc/RichEdit/Editor.cpp:455
455 s % unit;
(gdb) p version
$4 = 1
(gdb) p unit
$5 = 1
(gdb) s
Upp::Stream::operator% (this=0xbffe6c20, d=@0xbfffb67c) at /Users/lundman/src/upp/uppsrc/Core/Stream.cpp:585
585 SerializeRaw((dword *)&d, 1);
(gdb) s
Upp::Stream::SerializeRaw (this=0xbffe6c20, data=0xbfffb67c, count=1) at /Users/lundman/src/upp/uppsrc/Core/Stream.cpp:457
457 SerializeRaw((byte *)data, 4 * count);
(gdb) s
Upp::Stream::SerializeRaw (this=0xbffe6c20, data=0xbfffb67c "", size=4) at /Users/lundman/src/upp/uppsrc/Core/Stream.cpp:442
442 if(IsError()) return;
(gdb) n
447 }
(gdb) n
Upp::Stream::SerializeRaw (this=0xbffe6c20, data=0xbfffb67c, count=1) at /Users/lundman/src/upp/uppsrc/Core/Stream.cpp:459
459 EndianSwap(data, count);
(gdb) p data
$6 = (dword *) 0xbfffb67c
(gdb) p *data
$7 = 1
(gdb) n
461 }
(gdb) p *data
$8 = 16777216
(gdb) n
Upp::Stream::operator% (this=0xbffe6c20, d=@0xbfffb67c) at /Users/lundman/src/upp/uppsrc/Core/Stream.cpp:586
586 return *this;
(gdb)
587 }
(gdb)
Upp::RichEdit::SerializeSettings (this=0xbfff707c, s=@0xbffe6c20) at /Users/lundman/src/upp/uppsrc/RichEdit/Editor.cpp:456
456 s % showcodes;
(gdb) p unit
$9 = 16777216
Seems it is given a default value, then gets EndianSwapped, when maybe it should only be endianswapped when read?
|
Oops. I am stupid. There must be TWO swaps, one before SerializeRaw, second after it!
void Stream::SerializeRaw(word *data, dword count) {
#ifdef CPU_BE
EndianSwap(data, count);
#endif
SerializeRaw((byte *)data, 2 * count);
#ifdef CPU_BE
EndianSwap(data, count);
#endif
}
void Stream::SerializeRaw(dword *data, dword count) {
#ifdef CPU_BE
EndianSwap(data, count);
#endif
SerializeRaw((byte *)data, 4 * count);
#ifdef CPU_BE
EndianSwap(data, count);
#endif
}
void Stream::SerializeRaw(uint64 *data, dword count) {
#ifdef CPU_BE
EndianSwap(data, count);
#endif
SerializeRaw((byte *)data, 8 * count);
#ifdef CPU_BE
EndianSwap(data, count);
#endif
}
(later we most likely should speed optimize that)
Mirek
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: MacOS X woes [message #7299 is a reply to message #7292] |
Thu, 21 December 2006 02:21 |
lundman
Messages: 175
Registered: March 2006
Location: Tokyo
|
Experienced Member |
|
|
As requested, attached file.
I guess I could also mention two other things, they don't really affect the usage of U++, but sometimes perfection is desirable.
When a Window is minimized (or possibly removed) Console gets:
X Error: BadMatch (invalid parameter attributes), request: X_SetInputFocus, resource id: 6295038 = 600DFE
but it is just noisy, no noticable impact.
And when you exit the Ide:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x000004d0
0x00f20468 in XQueryExtension ()
(gdb) bt
#0 0x00f20468 in XQueryExtension ()
#1 0x00f161c0 in XInitExtension ()
#2 0x018bf34c in XextAddDisplay ()
#3 0x00df11e0 in XRenderFreePicture ()
#4 0x00320568 in Upp::Image::Data::SysRelease (this=0x1bd3488) at /Users/lundman/src/upp/uppsrc/Draw/ImageX11.cpp:63
#5 0x002fdbf4 in Upp::Image::Data::~Data (this=0x1bd3488) at Image.cpp:324
#6 0x005850dc in Upp::Image::Data::Release (this=0x1bd3488) at Image.h:117
#7 0x002fdd04 in Upp::Image::~Image (this=0x200993c) at Image.cpp:278
#8 0x0044928c in Upp::Iml::IImage::~IImage (this=0x2009938) at Image.h:253
#9 0x0045a694 in Upp::DestroyArray<Upp::Iml::IImage> (t=0x2009938, lim=0x2009a10) at Topt.h:175
#10 0x0045a76c in Upp::Vector<Upp::Iml::IImage>::Free (this=0x91ea40) at Vcont.hpp:101
#11 0x0045a80c in Upp::Vector<Upp::Iml::IImage>::~Vector (this=0x91ea40) at Vcont.h:82
#12 0x0045a848 in Upp::AMap<Upp::String, Upp::Iml::IImage, Upp::Vector<Upp::Iml::IImage>, Upp::StdHash<Upp::String> >::~AMap (this=0x91ea04) at Map.h:2
#13 0x0045a8c0 in Upp::VectorMap<Upp::String, Upp::Iml::IImage, Upp::StdHash<Upp::String> >::~VectorMap (this=0x91ea00) at Map.h:130
#14 0x0047571c in Upp::Iml::~Iml (this=0x91e9f4) at Image.h:252
#15 0x002ae584 in __tcf_0 () at iml_source.h:54
#16 0x00003a44 in cxa_atexit_wrapper ()
#17 0x9001455c in __cxa_finalize ()
#18 0x90014444 in exit ()
#19 0x00002c58 in _start ()
#20 0x00002958 in start ()
But all files are saved correctly, so again, no impact, just not "clean". I used File/Exit there, but same happens when you push Close X-icon.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: MacOS X woes [message #7351 is a reply to message #7342] |
Sat, 23 December 2006 10:58 |
lundman
Messages: 175
Registered: March 2006
Location: Tokyo
|
Experienced Member |
|
|
It was your fix
Color.h:
#ifdef PLATFORM_WIN32
struct RGBA : Moveable<RGBA> {
byte b, g, r, a;
};
#endif
#ifdef PLATFORM_POSIX
#ifdef CPU_BE
struct RGBA : Moveable<RGBA> {
byte a, r, g, b;
};
#else
struct RGBA : Moveable<RGBA> {
byte b, g, r, a;
};
#endif
#endif
#ifndef PLATFORM_WIN32
"path" is defined in .lay, I checked, but it just doesn't want to compile
bmphdr (looks like no change):
/Users/lundman/src/upp/uppsrc/plugin/bmp/bmphdr.h: In member function 'void Upp::BMP_FILEHEADER::SwapEndian()':
/Users/lundman/src/upp/uppsrc/plugin/bmp/bmphdr.h:18: error: no matching function for call to 'Upp::BMP_FILEHEADER::SwapEndian(Upp::word&)
'
/Users/lundman/src/upp/uppsrc/plugin/bmp/bmphdr.h:15: note: candidates are: void Upp::BMP_FILEHEADER::SwapEndian()
/Users/lundman/src/upp/uppsrc/plugin/bmp/bmphdr.h:19: error: no matching function for call to 'Upp::BMP_FILEHEADER::SwapEndian(Upp::dword&
)'
etc
|
|
|
|
Goto Forum:
Current Time: Sat Apr 25 14:42:39 GMT+2 2026
Total time taken to generate the page: 0.01012 seconds
|
U++ framework
Search
Help
Members
Register
Login
Home
