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 » Developing U++ » Mac OS » MacOS X woes
MacOS X woes [message #7137] Fri, 15 December 2006 13:52 Go to next message
mirek is currently offline  mirek
Messages: 11963
Registered: November 2005
Ultimate Member
lundman wrote on Fri, 15 December 2006 07:22


Got it and recompiled all, but no difference, core the same place, the same backtrace. At what place to you pull out the number of images so I can check we are getting a sane value? All I see is zeros.






Well, it is a little bit complicated....

There are two .iml formats.

I guess we are dealing here with newer one. In the new format, there are image headers (with names) and images are compressed in about 4KB blocks (because compressing several small images together yields better compression ratio than compressing them individually).

The problem here is most likely that number of headers does not match number of images in compression blocks (there is more headers).

The critical function to investigate first is IMHO:

Vector<Image> UnpackImlData(const String& d)

placing a couple of LOGs and DUMPs there might reveal what is going on.

BTW, moving this to the forum...

Mirek
Re: MacOS X woes [message #7139 is a reply to message #7137] Fri, 15 December 2006 14:07 Go to previous messageGo to next message
lundman is currently offline  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 Go to previous messageGo to next message
lundman is currently offline  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 #7141 is a reply to message #7140] Fri, 15 December 2006 14:19 Go to previous messageGo to next message
lundman is currently offline  lundman
Messages: 175
Registered: March 2006
Location: Tokyo
Experienced Member

If I'm posting too much, just tell me off Smile

#1  0x002ffbd0 in UnpackImlData (d=@0xbffff78c) at ImageBlit.cpp:237
237                     ImageBuffer ib(Peek16le(s + 1), Peek16le(s + 3));

(gdb) x/16x s
0xffb014:       0x000d000d      0x00010001      0x00000000      0x00000000
0xffb024:       0x00000000      0x00000000      0x00b2b2be      0xff676789



So +1, and +3 should be 0d00 0d00, in LE, or rather, 13x13. However, I get 3328. ($D00) Peek16le isn't flipping?
Re: MacOS X woes [message #7142 is a reply to message #7140] Fri, 15 December 2006 14:25 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 11963
Registered: November 2005
Ultimate Member
lundman wrote on Fri, 15 December 2006 08:10


Actually, its just size.cx*size.cy and at 3328 pixels each, that is the right value. So assuming 3328x3328 is correct..



...but 3328 almost certainly is not...

-> is 0xd00, 0x00d is much more realistical (first picture in the .iml is 13x13 pixel image).

We are definitely getting nuxi problem here...

Are you sure that Peek16le is in correct version? (Maybe just preprocess the file and look.)

Mirek
Re: MacOS X woes [message #7155 is a reply to message #7142] Sat, 16 December 2006 02:30 Go to previous messageGo to next message
lundman is currently offline  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 #7156 is a reply to message #7155] Sat, 16 December 2006 02:49 Go to previous messageGo to next message
lundman is currently offline  lundman
Messages: 175
Registered: March 2006
Location: Tokyo
Experienced Member

I can confirm that with the following hack

ImlFile.cpp:112

            if (image.size.cx > 1000) {
              image.size.cx = 16;
              image.size.cy = 16;
            }

...since I know that my two icons are 16x16...

The image editor loads without core dumping, and displays my first icon just fine.

Re: MacOS X woes [message #7166 is a reply to message #7155] Sun, 17 December 2006 15:03 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 11963
Registered: November 2005
Ultimate Member
lundman wrote on Fri, 15 December 2006 20:30


When I rsynced the new Util.h it over-wrote my port changing, including setting of flagPPC.



Ooops. Can you post the patch please so that I can apply it?

Quote:


Anyway, back to where we were, looking at the image editor segv.



Based on the code, looks like problem in serialization. Will look at it asap.

Mirek
Re: MacOS X woes [message #7171 is a reply to message #7166] Sun, 17 December 2006 15:22 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 11963
Registered: November 2005
Ultimate Member
Coonfirmed&fixed (well, at least I hope).

In the process, I have encountered an interesting problem - serialization of float and double.

How is the float/double format on PowerPC (or other non-x86 CPUs)? Is it the same, just needing to swap the order of bytes like integer types?

Mirek
Re: MacOS X woes [message #7172 is a reply to message #7171] Sun, 17 December 2006 15:38 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 11963
Registered: November 2005
Ultimate Member
OK. It really seems like fp numbers are the same, just swapped. Altering code to this..

Mirek
Re: MacOS X woes [message #7188 is a reply to message #7172] Mon, 18 December 2006 03:33 Go to previous messageGo to next message
lundman is currently offline  lundman
Messages: 175
Registered: March 2006
Location: Tokyo
Experienced Member
I stepped through the serialisation code earlier to confirm it did indeed break endianess. (File is saved in little). After setting the sizes to 16x16 it became saved in big-endian and just worked but that's not ideal either Smile

Changes for OSX11 are:

Package Organiser:

CtrlLib: Add Package, When "OSX11": PdfDraw
Draw: New Libraries, When "OSX11": X11 Xft fontconfig Xrender freetype expat


Only patching that is questionable is the plugin/bmp/bmphdr.h with my extra casting.

So currently, you set "flagPPC" or "flagX86" in the Build Environment variables. This will trigger code to add "-arch X" for cc and lnk times.


  • Attachment: osx11_patch
    (Size: 5.51KB, Downloaded 283 times)
Re: MacOS X woes [message #7189 is a reply to message #7188] Mon, 18 December 2006 03:48 Go to previous messageGo to next message
lundman is currently offline  lundman
Messages: 175
Registered: March 2006
Location: Tokyo
Experienced Member
Hmm, seems that -DflagPPC does not trigger the code with
HasFlag("PPC") so that won't work either.

Need to be able to trigger extra linking variables (since they can not be specified in Build Environment).

I guess I could change it so that you specify "-arch ppc" or "-arch i386" in BE instead, then add:

Core/Core.h:

        #ifdef __BIG_ENDIAN__
                #define flagPPC
                #undef flagX86
        #endif

        #ifdef __LITTLE_ENDIAN__
                #undef flagPPC
                #define flagX86
        #endif

(those endian defines are set by gcc based on the -arch flag)

then I can add linking flags in GccBuilder.cpp.

Which way to do you prefer?

Re: MacOS X woes [message #7190 is a reply to message #7189] Mon, 18 December 2006 08:28 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 11963
Registered: November 2005
Ultimate Member
Hm, what this says

http://developer.apple.com/qa/qa2005/qa1424.html

?

Maybe for the moment, we could use some of predefined macros...

Mirek
Re: MacOS X woes [message #7192 is a reply to message #7190] Mon, 18 December 2006 09:28 Go to previous messageGo to next message
lundman is currently offline  lundman
Messages: 175
Registered: March 2006
Location: Tokyo
Experienced Member

Yeah I'm okay with that. I will change it to be as shown above, and we specify the build type with "-arch" in BuildEnv. Then the lnk additions will also work.

Re: MacOS X woes [message #7193 is a reply to message #7192] Mon, 18 December 2006 10:36 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 11963
Registered: November 2005
Ultimate Member
lundman wrote on Mon, 18 December 2006 03:28


Yeah I'm okay with that. I will change it to be as shown above, and we specify the build type with "-arch" in BuildEnv. Then the lnk additions will also work.




Well, I am afraid that __LITTLE_ENDIAN__ could bite us with ARM. Is not there some __power_pc__ macro?

Mirek
Re: MacOS X woes [message #7198 is a reply to message #7193] Mon, 18 December 2006 10:53 Go to previous messageGo to next message
lundman is currently offline  lundman
Messages: 175
Registered: March 2006
Location: Tokyo
Experienced Member
#define __ppc__ 1
#define __POWERPC__ 1
#define _ARCH_PPC 1

Last one could be interesting.

Similarly:

#define i386 1
#define __i386 1
#define __i386__ 1
Re: MacOS X woes [message #7201 is a reply to message #7198] Mon, 18 December 2006 11:15 Go to previous messageGo to next message
lundman is currently offline  lundman
Messages: 175
Registered: March 2006
Location: Tokyo
Experienced Member

Although I should mention I put the #ifdef ENDIAN inside that of PLATFORM_OSX11 so it shouldn't matter, but based on arch is better than endianess Smile

Re: MacOS X woes [message #7206 is a reply to message #7201] Mon, 18 December 2006 13:50 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 11963
Registered: November 2005
Ultimate Member
Another small issue: Maybe instead CPU_PPC it should be CPU_POWERPC, because PPC clashes with PocketPC a bit...

Mirek
Re: MacOS X woes [message #7227 is a reply to message #7206] Tue, 19 December 2006 01:15 Go to previous messageGo to next message
lundman is currently offline  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 Go to previous messageGo to previous message
lundman is currently offline  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.

Next Topic: 701-dev1 / 2007.1beta on Mac OSX
Goto Forum:
  


Current Time: Tue Jul 23 02:31:17 CEST 2019

Total time taken to generate the page: 0.01688 seconds