When ever I try to push my app to my ipad or ipod to test them I get this error...
alignment lost in merging tentative definition _resultbuffer.
What is it? Any idea how to fix it?
I'm going to take a wild guess here, apologies if I'm too far off the mark:
On the ARM processor alignment can be an issue, particularly if you're accessing a variables in an unaligned manner, I suspect this is what you're seeing:
Here's a couple links that might see you through this:
gcc type-attributes documentation (Yes, I know its compiling with clang, this still may help)
Basically the same thing from ARM's documentation
A pretty good write-up about ARM alignment and how to avoid problems
Most flavors of ARM will automatically 'fix' this by adjusting the alignment on the fly, however this is configurable. The down-side is it causes a CPU interrupt to handle it, so if you're doing this over and over it'll slow things down. I haven't run into this on iOS, so I can't say for sure what the behavior would be. Odds are its best just to fix it.
Related
I starting to look into porting my application from Gtkmm 3.24 to Gtkmm 4.x (not sure which version yet). For now, I am only trying to understand what exactly is deprecated and how much work is needed for planning. One way to ease porting is to look into all deprecated usages in the Gtkmm 3.24 version and update them to the newer flavor before porting. I have found several macros that can help with that:
GTKMM_DISABLE_DEPRECATED
GDKMM_DISABLE_DEPRECATED
GLIBMM_DISABLE_DEPRECATED
GIOMM_DISABLE_DEPRECATED
When I #define these, the compiler throws error when meeting deprecated stuff because they have been disabled. This is nice, once the code is leveled up, to make sure the code stays free of deprecated usages.
In my case, however, the code is still full of deprecations and the compiler stops compilation on the first deprecation it meets. This does not help me much in understanding where the deprecations lie and how much work is needed. I could go about and solve every error, one by one, until there is no more (this is ultimately what I will do) but I can't know ahead how much time this will take.
What I would really like are macros that throw warnings when meeting deprecation, but let the compiler go on about building. This way I could get a list of everything that is deprecated in my codebase and plan work appropriately. I have browsed the Gtkmm documentation and codebase but found nothing.
Do such macros exist and if so, what are they?
The solution was to use
GTKMM_DISABLE_DEPRECATED
GDKMM_DISABLE_DEPRECATED
GLIBMM_DISABLE_DEPRECATED
GIOMM_DISABLE_DEPRECATED
like I did but to use the -k flag with make. From man make:
-k, --keep-going
Continue as much as possible after an error. While the target
that failed, and those that depend on it, cannot be remade, the
other dependencies of these targets can be processed all the same.
Source: Inkscape GTK+ 3 migration wiki page.
Some time ago (a year?) we ran into problems with debug builds that had whole module optimization enabled. When tracing, the debugger would jump to unexpected addresses. Since then, we've been shy about enabling this on our debug builds. We do enable it for our release builds.
Is anyone aware of any existing --- even subtle --- issues with debugging an executable that has been optimized this way?
Or, conversely, has everything been working fine for you with this configuration?
From what I understand it should not cause issues as whole module optimisation mainly means that Swift knows what it can directly address ( a straight up _call ) compared to a VTable lookup as well as reduce the costly retain release cycles.
Similar to this, it is a good idea in general to use access control in swift right when you writing your code. privatizie everything unless you really need to access it outside. Use final on classes that don't need subclassing etc.
Usually when you enter the assembly view in Xcode is because of symbols missing for the debugger on libraries being called.
A small tip for debugging: I recently found a bug in my own code when implementing a TLS socket by simply looking up the address and the referenced method, downloading the source and looking up what was missing or causing the issue.
Now that said, in general it will greatly increase debug build times so do you have any reasons for running -whmo in debug?
My app freezes in Release configuration only.
I tracked down the issue to this setting:
It is no secret that the Swift compiler is buggy.
I have never seen a compiler crash (and crash often).
So, is it "safe" to submit to the App Store with Optimisation Level set to "None"?
Any experience?
Apple does not recommend shipping your application with no compiler optimizations.[1]
None: The compiler does not attempt to optimize code. Use this option
during development when you are focused on solving logic errors and
need a fast compile time. Do not use this option for shipping your
executable.
Taken from apple.developer.com.
While compiler optimization bugs exist,[2] Xcode is probably not the source of the problem, as explained in the answer provided here by the stackoverflow user #kfmfe04:
In some extremely rare cases, the debug code works, but the release
code fails. When this happens, almost always, the problem is in my
code; aggressive optimization in release builds can reveal bugs caused
by mis-understood lifetimes of temporaries, etc...
Remember that you can always track down the source of the problem by examining the compiled assembly file, but it will require some ASM knowledge to understand what the compiler is doing under the hood.
In Xcode options:
Debug -> Debug Workflow -> Always Show Disassembly
Then you put a breakpoint where you want to check the ASM code.
After migrating from XCODE 4 to 4.2 i have quite a few problems with my applications, many of them due to my own bad code quality.
As an example i had for some reason done two calculations looking like:
xx = xx++
...which worked in XCODE 4 but not in 4.2 where the compiler jumped over and did not either process or warned about it. This took me a week to find&fix even if i tried to read-up on the differences between 4 and 4.2.
Changed it to:
xx++
..so it works now :-)
However, i still have problems so i wonder if someone could point me to where i can read about these type of "smaller but important" differences, which hopefully can help me track the other issues down.
Cheers
Welcome to the wonderful world of undefined behaviour. These sorts of changes are not often documented, because they only occur when you break your contract with the compiler.
See this question (it is related to C++, but there are a lot of common undefined behaviours between C++ and Objective-C) for some more examples.
At work we use confluence.
On occasion it crashes, resulting in an error 500 page being generated.
This page includes some interesting reference information, including:
System Information:
favouriteColour: Myrtle
javaRuntime: Java(TM) SE Runtime Environment
jvmVersion: 1.0
operatingSystem: Linux 2.6.18-92.1.13.el5
...
Myrtle?
Many thoughts raged through my head. What's Myrtle? Why is it my favourite colour? Is it my favourite colour? Why does that particular tidbit of information require its own system property?
At first I assumed it was just something that someone at work had done. A remnant of a project long forgotten, an old April Fools joke perhaps?
It seems I was mistaken. In fact, even Atlassian acknowledges the colour, though they give no reason for its existence.
Now, I know what you're thinking? Who cares?
I do, gentle reader, I do. And you should too. It's little mysteries like this that make life worth living.
So, is there one among you who knows the secret of The Mysterious Myrtle uh.. Mystery? At least one inquiring mind wants to know..
Your Confluence System Favourite Colour (Australian spelling FTW) is also available from Admin -> System Info.
And if I told you any more, I'd have to kill you.
This looks like an obfuscation of their version or the error number.
You're not supposed to give your exact version away when selling corporate enterprise systems - it supposedly makes it easier for hackers to know what vulnerabilities to hit.
However they still want to be able to know what version you're on or what error id you got when you call for technical assistance, so they have a code word for each release.
I suppose the colours run out pretty quickly.
Maybe it's something incredibly fundamental to programming - like pi for math, 42 for the universe, or the L-unit for space travel (as we all know, without it, space travel is but the fevered dream of a madman).
We can only guess.
FWIW, I've frequently put "interesting" information in error dumps -- I've found it's easier to get people to report it in bug reports, and they're more likely to accurately report something like "myrtle" as opposed to "error #47" or whatever...