Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I was checking the portability of a tool using Z3 (2012-12-21 git version, the latest "master" release), and thus tried compiling Z3 on Sparc64. I had to fiddle with src/util/hwf.cpp so that it would treat Sparc64, and not just IA64, as lacking SIMD intrinsics and emmintrin.h. The compilation succeeded.
Unfortunately, the resulting executable crashes on startup with a bus error in prime_generator::prime_generator(). I have no idea why.
Program received signal SIGBUS, Bus error.
0x009b1dac in global constructors keyed to _ZN15prime_generatorC2Ev ()
(gdb) bt
#0 0x009b1dac in global constructors keyed to _ZN15prime_generatorC2Ev ()
This is not very important for me (our machines are x86 or x86-64) but may be relevant for some embedded applications.
I don't think there has been any interest in running Z3 on non-x86 machines, so it's highly likely that you'll find a few problems.
SPARC, in particular, doesn't allow unalighed memory accesses, as x86 does.
From a quick look, I could see several points where the unaligned could come from.
For example, memory::allocate() dealigns the pointer returned by malloc by sizeof(size_t). If that's not 64 bits, then it will crash (because of the svector data).
Then, svector allocation, also reserves 2*sizeof(unsigned) before the data. If 2*sizeof(unsigned) is not a multiple of sizeof(uint64), then you'll get a crash.
And so on. The point is that without more info, it's impossible to help you. You need to compile with -g, and if needed print the assembly code where it's crashing to help pin point the exact location.
Also, don't use the master branch, please. That's very old. Please consider using the unstable branch (it's not that bad as the name may sound :)
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I want to decompile a iOS 3.1.3 kernel to better understand it, but i'm not sure where to start, But don't be fooled i'm no green horn when it comes to programming.
The kernel is open source so you can view and compile it. iOS 3.1.3 is in the repo but you will also want to look at 3.0.
From Apple:
As the first major computer company to make Open Source development a key part of its ongoing software strategy, Apple remains committed to the Open Source development model. Major components of Mac OS X, including the UNIX core, are made available under Apple’s Open Source license, allowing developers and students to view source code, learn from it and submit suggestions and modifications.
The XNU kernel in its iOS incarnation is not open source, though xnu in its i386/x86_84 (and , for older versions PPC) is.
XNU is built up internally of several layers, with the bottom two - platform expert and ml_* APIs serving as the "glue" to the underlying hardware. This means that without said pieces you could compile the source (with an ARMv7 cross compiler, like the one in the iPhone SDK), but the kernel wouldn't actually boot.
Another difficulty is in the kernel extensions (XNU-speak for "modules"). These are drivers, without which you can't really do much - again, with the kernel not booting since it can't initialize any of its platform dependencies.
Also, contrary to how it may seem, though the iOS and OS X kernels are very similar, there are some subtle differences (which were visible by #ifdef CONFIG_EMBEDDED and #ifdef ARM until after 1699, when Apple realized they were leaking information of use to jailbreakers, and finally used a preprocessor to strip the iOS specific modifications before making it public.
Decompilation is a different matter. It's possible to disassemble and work back, from the kernel image (once decrypted or dumped) through fairly readable assembly (though not to a full source level). IDA and other specialized tools (e.g. jtool) have these capabilities.
There have been at least two projects to get the open source version to compile and boot for ARM. One by Christina Brooks(?) and another by WinOCM. The latter, which has gained notoriety for knowing XNU in its ARM implementation inside out, has eventually been employed by Apple, thereby reducing the chance of any open source implementation ever seeing the light of day.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 1 year ago.
Improve this question
Previously with objective-c code, I could "Analyze" - CMD + Shift + B and Xcode would warn me of all kinds of wrongdoings on my part.
It seems that with Swift, I can do no wrong! No warnings of any kind! But clearly there is a memory leak in my code.
Is there some setting I have to enable to get Swift to analyze my code properly? (I am aware I should use the profiler and test on an actual device, which I do, but I wonder why "Analyze" doesn't do anything.
Unfortunately no. Even many releases later, the latest version of XCode (6.4) still cannot do Swift analysis. The 'Analyze' option only works for the Objective C files in your project.
Let's hope the next version will have it, along with the refactoring capabilities which also are still limited to Objective C code.
To this moment (Xcode 8.3.x) Static Code analysis skips Swift code. Some Swift warnings cover some of the issues previously detected by the analyzer.
Also the upcoming Xcode 9 (presented in WWDC 2017) does not announce any change in this direction.
Many issues detected by the static Analyzer of Obj-C are for the most part prevented by the actual Swift language (e.g. unintended fall-through in switch statements). Other issues and scenarios formerly caught by the analyser, are now caught directly by the Swift compiler.
Many flows and scenarios leading to program crash - (e.g. accessing null pointers, leaving dangling pointers, or accessing released memory blocks) are hardly possible in Swift. Swift strong typing, heavy use of optionals, the requirement to completely cover protocols, and switch-case over enums, etc. remove another bunch of issues previously found by the analyzer.
A Swift static code analyzer will need to go to another level in analyzing program logic, which is much harder, and theoretically impossible to do completely.
So - although I'm quite thrilled to think of some future Xcode Analyzer, I wouldn't hold my breath waiting for it
Update:
As more and more people are down voting my post, just small update from my side. It seems that indeed apple just did allow for pressing option "Analyze" but in the background it does nothing (state for 2016.04.21, though I am not working on iOS for the moment and probably I don't have the latest version of Xcode).
below my original post:
Just for next readers of this article. At this moment Xcode 7 is already able to analyze also Swift projects. Refactoring is still not working though.
BR,
Darek
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 years ago.
Improve this question
Do they use some algorithm such as the ones used in GDIFF program?
Do they ship the intermediate code to the user instead of iOS binary?
Why is it not possible do do a Delta update while updating iOS on Windows?
A delta update is defined as 'an update that only requires the user to download the code that has changed, not the whole program.'
iOS does, in fact, perform delta updates, and contradictory to Ralph's comment, we know exactly how it works.
Applications
For iOS applications, delta updates are used to minimize the download size of new versions, to save internet traffic. Usually, the things that give a program most of its size are the static images and other media. During a simple update such as a bug fix, usually these static images stay the same, and there is no reason to send them over the network again. The only thing that is sent is the actual Mach-O binary containing the code that is buggy, along with whatever files have been changed.
So, delta updates most likely run by checksumming. When you submit an app update, Apple checks the checksum of all files submitted using some algorithm (most likley SHA1 or MD5) to scan for changes. If the executable has changed, but a certain image or other file has not, the image isn't packed with the update, as users have already downloaded it, and don't need to download it again. While this method may not pertain exactly to the definition of a delta update, as it includes executables along with other types of files, it has very similar concepts.
OTA Updates
Apple uses delta updates in over-the-air updates for iOS as well. This is visible on any jailbroken iOS device. Updates are downloaded to /var/MobileSofwareUpdate/softwareupdate.xxxx, where xxxx presumbably is the build/release number. Each software update contains an image of the root filesystem, but not the entire version of iOS is included. Only the files that have changed from the version the user is currently on need to be replaced, and so only those files are included in the update package. The method for finding these changes is likley to be the same as with iOS apps, where checksumming finds changes in the files.
Algorithm
Basically, to answer your question, Apple's algorithm doesn't send the differences between two individual files (similar to what you see in a git commit), but sends the entire updated file. Their 'algorithm' just looks for any change at all between the last version, and doesn't look for the actual change itself. This is proven by the fact that in OTA update packages, the complete files are available, and not just a log of the changes.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
Just for fun, I'm trying to hack my saved game data for the Ghostbusters iPhone app (AppStore link).
The following sites describe replacing Documents/save.dat with the pre-hacked version:
http://www.iapphacks.com/ios-free-hacks-f3/ghostbusters-v1-0-1-t8597.html
http://mobilegamingsquad.wordpress.com/2013/01/24/ghostbusters-hack/
However, I want to modify the data myself. Using a hex-editor on my save.dat revealed the following dead-ends:
I could not find the value for the amount of money in any combination of the following: (little endian, big endian), (unsigned, signed), (integer, float), (4, 6, 8, 16 byte value), (1 through 15 byte offsets)
Any small change (ie: item purchase) seems to completely rewrite and change the data file.
A quick scan of the file in ASCII reveals no text clues to the format of the file. ADD: In fact, all ASCII strings within the file seem completely random.
The linux command file simply identified the file as data.
NEW Compressing the file enlarges it, so the file is likely compressed or encrypted.
NEW I'm neither jailbroken nor an iOS developer, so I do not have access to the app's internal memory.
How might this file be encoded? Any suggestions on how I might modify it manually?
I have done something similar just for the fun of it. In my case, the file was compressed and contained a hash signature with a salt value generated by the game executable. In that case, I used gdb, set breakpoints on all hash functions and inspected their arguments. I am actually not sure how one would go about debugging an iPhone application, but I suspect it is not possible unless you jailbreak the device, so you are probably stuck trying to analyze the files.
Start by downloading HexField (or a similar tool), it is really great for this type of work. Try to find a pattern based on really small changes (try really hard to change as little as possible, and make sure you kill the game after changing something). If you are lucky, the scores, money and whatnot is just obfuscated.
If do not easily see a pattern in the file I would start by investigating known compressions such as gzip (without header), deflate, lzma, etc (start by looking at the symbol table and use class-dump on the game binary for some ideas). Since the file command gave nothing, I assume the file is not simply gzipped.
Failing that, you may start to suspect that the file is encrypted (again, look at the symbol table). A good way to determine if the file is compressed or encrypted is to try to compress it. If no algo is able to compress it further, it is very likely that the file is either compressed or encrypted.
Happy hacking! :)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
Is there a logging framework for iOS that could aid developers in diagnosing app crashes?
You may like:
Lumberjack: stable and traditional
"It is similar in concept to other popular logging frameworks such as log4j, yet is designed specifically for Objective-C, and takes advantage of features such as multi-threading, grand central dispatch (if available), lockless atomic operations, and the dynamic nature of the Objective-C runtime."
LibComponentLogging: beautiful and hardcore, used by RestKit
"LibComponentLogging is a small logging library for Objective-C applications on Mac OS X and the iPhone OS which provides conditional logging based on log levels and log components. Additionally, different logging strategies can be used, e.g. writing log messages to a file or sending them to the system log, while using the same logging interface."
NSLogger: fancy with a dedicated visualization OS X App
"NSLogger is a high perfomance logging utility which displays traces emitted by client applications running on Mac OS X or iOS (iPhone OS). It replaces your usual NSLog()-based traces and provides powerful additions like display filtering, image and binary logging, traces buffering, timing information, etc."
I know this post is old but I'm looking for one as well. I found one called Lumberjack, though I haven't tried it yet.
I created a simple logging framework that might help. I'd appreciate any feedback you have. Hope it helps.
Link to Project Page
This previous question seems to overlap. But the bottom line is:
NSLog(#"message");
or:
printf("message");
I have a slightly different need: not only do I want to debug crashes, but I also need to debug other errors (NSError, NSException).
I tried all 3 packages mentioned in IlDan's answer. However, all of them require me to adopt a new way of logging, which may not be compatible with the libraries I depend on. For example, I intended to adopt NSLogger but RestKit, which is an important library in my project, uses LibComponentLogging.
So I ended up with writing a small pod (https://github.com/kennethjiang/Teleport-NSLog) for that. The mechanism is to redirect stderr (where NSLog + all these logging frameworks write messages to) to a backend HTTP server. Now I can debug my app running in user's device just as if it was running in my xcode. :)
For basic logging use NSLog(#"your message here")
If you want more flexible logging look into Lumberjack. It can let you disable logging in production etc etc.