We have started seeing a strange problem, appearing somewhat out of nowhere, where the compiler segfaults in handleDeferredImports. This doesn't always happen, sometimes I need to clean & rebuild 2-3 times to trigger it again, so it's very hard to determine what's the root cause of it.
I've also not been able to reproduce it in a separate sample project, but after two days of looking for solutions I'm drawing a blank.
This is the segfault: error: Segmentation fault: 11 with following stack:
0 swift 0x000000011307064a PrintStackTraceSignalHandler(void*) + 42
1 swift 0x000000011306fdfe SignalHandler(int) + 302
2 libsystem_platform.dylib 0x00007fff76391b3d _sigtramp + 29
3 libsystem_platform.dylib 000000000000000000 _sigtramp + 2311513312
4 swift 0x0000000110605df0 swift::ClangImporter::Implementation::handleDeferredImports() + 512
5 swift 0x00000001106058dc swift::ClangImporter::Implementation::importHeader(swift::ModuleDecl*, llvm::StringRef, swift::SourceLoc, bool, std::__1::unique_ptr<llvm::MemoryBuffer, std::__1::default_delete<llvm::MemoryBuffer> >, bool) + 1804
6 swift 0x0000000110606754 swift::ClangImporter::importBridgingHeader(llvm::StringRef, swift::ModuleDecl*, swift::SourceLoc, bool, bool) + 932
7 swift 0x000000011010acfd swift::CompilerInstance::performSema() + 2029
8 swift 0x000000010f2f859b performCompile(swift::CompilerInstance&, swift::CompilerInvocation&, llvm::ArrayRef<char const*>, int&, swift::FrontendObserver*, swift::UnifiedStatsReporter*) + 731
9 swift 0x000000010f2f4dc5 swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, swift::FrontendObserver*) + 7717
10 swift 0x000000010f29aa35 main + 1349
11 libdyld.dylib 0x00007fff761a808d start + 1
12 libdyld.dylib 0x0000000000000123 start + 2313519255
There's no indication to individual files or headers.
We do use a mix of Objective-C and Swift, importing ProjectModuleName-Swift.h in a lot of files, and similar, have a very large ProjectModuleName-Bridging-Header.h file. In addition to this, for legacy reasons, there's a ProjectModuleName-Prefix.pch for default Objective-C includes (yes, I know that's awful).
What's strange here is the segfault in handleDeferredImports which is different from all the other Swift compiler segfault issues found on Stack Overflow.
Swift version is 4.2, and we're using the "New Build System" in Xcode 10 (it also segfaults on the "Legacy Build System").
Workaround for the Swift 4 compiler was to enable Whole Module optimisation for all builds.
The issue itself appears to been fixed in Swift 5.0
Should anyone see this issue in the future, please refer to https://bugs.swift.org/browse/SR-9528
I got a crash log from Crashlytics, see below. I don't know what + 56 means in line 3. I am not sure if it is related to line number in the source code.
Crashed: com.apple.main-thread
0 libobjc.A.dylib 0x1826f0910 objc_msgSend + 16
1 CoreFoundation 0x183406360 -[NSDate timeIntervalSinceDate:] + 56
2 BLESupport 0x10084a63c -[CustomPeripheral getDeviceParamsDidFinish:dictionary:paramType:error:] + 380
3 BLESupport 0x100850ab4 -[CustomPeripheral peripheral:didUpdateValueForCharacteristic:error:] + 4032
The "+ 56" is an offset in the compiled binary, not a line number in the source code.
1 CoreFoundation 0x183406360 -[NSDate timeIntervalSinceDate:] + 56
Xcode provides you to backtrace log and provides information about active frames to help you trace the issue.
The above crash log can be understand as follows.
1 - that is the frame at which it was crashed. 0 is the top most
CoreFoundation - it is the responsible framework behind the crash.
0x183406360 - the address on the disk at which timeIntervalSinceDate function exists.
[NSDate timeIntervalSinceDate:] + 56 - This is the important part, where it says about the function and + 56 is an offset from function address that crashed.
Thanks matt for pointing it out.
EDIT:
Basically, there are three types of crash reports
unsymbolicated - This contains only addresses and offset
Partially Symbolicated - This shows Base Address Of Method + Method Name + Offset From the base address
Fully Symbolicated. - This shows base address + Method Name + FileName:LineNumber
Hope it helps.
The convention used is:
<address> <name of symbol> <offset into symbol> <line number>
So, for your line 3, above, the + 56 indicates that the PC was 56 bytes into the function -[NSDate timeIntervalSinceDate:]. It is not the line number.
In order for Crashlytics, or any other service to provide line number information, they need access to debug symbol information. A very common source of this information is a dSYM. So, in order to provide line number information for this NSDate function, you'd need the dSYM for CoreFoundation. Only Apple has this. Of course, since you don't have the code for this function anyways, having the line number probably wouldn't help very much.
So I've been trying to figure out how to decompile dlls, java, and Lua files but once I ran into this one I got stumped.
Does anyone have any ideas on how I can decompile this?
Since the script was way too big I put it in a pastebin link. https://pastebin.com/UsdWEHnmIlIIl1liIllIi1II1Ii.lIl1llIllIii1111lIIIii = lIli1IlI11lIlI1il11i1() lIli1IlI11lIlI1il11i1() lIli1IlI11lIlI1il11i1() local ll1ili1i1Ii1II111li = lIlIlll1Ill1illiliIiI() for i1IiIili111iI1lil1l = lIliI1iii11lilII1IIil, ll1ili1i1Ii1II111li do IlIIl1liIllIi1II1Ii.l111II111Il1IiIII11i[i1IiIili111iI1lil1l] = lIlIlll1Ill1illiliIiI() end lIlIlll1Ill1illiliIiI() lIli1IlI11lIlI1il11i1() lIli1IlI11lIlI1il11i1() lIlIlll1Ill1illiliIiI() lIlIlll1Ill1illiliIiI() lIlIlll1Ill1illiliIiI() lIli1IlI11lIlI1il11i1() local ll1ili1i1Ii1II111li = lIlIlll1Ill1illiliIiI() - (#{ 91625, 31274, 132907, 128929, 89879, 28353, 85846, 63662, 120975, 94604, 40073, 120271, 29175, 126728, 55753, 31423, 118592, 112751, 123563, 26653 } + 49 - 22 - 12 + 24 + 10 + 32 - 27 + 22 - 35 + 41 + 25 + 29 + 18 + 33 + 32 + 133485) for i1IiIili111iI1lil1l = lIliI1iii11lilII1IIil, ll1ili1i1Ii1II111li do local l1iI1Illil1i1il1iII = {} local lIlill1IIIlli1iII1ill = lIlIllI1i111lilIi1ilI(i1iIIIii1liiIillilI) l1iI1Illil1i1il1iII.il1li1iilIii1iIll11l = iiIlIlilIlIll1l1l1l(lIlill1IIIlli1iII1ill, #{ 19814, 81950, 109054, 18321, 117777, 126276, 941, 40833, 27393, 25354, 106568, 58140, 73781, 28751, 110509, 42721, 118305, 94680, 18166, 4591 } + 26 - 9 + 9 - 4 - 48 - 2 + 24 + 47 - 35 - 8 - 31 - 1 + 39, #{ 34453, 33661, 37020, 5461, 3935, 7245, 90253, 30010, 122438, 78286, 50375, 62446, 101176, 126539, 91679, 59085, 67167, 93133, 73148, 54067, 13807 } + 29 - 46 - 15 + 41 + 32 - 26 + 6 - 6 + 27 - 43 + 12 - 17 + 11 + 6) l1iI1Illil1i1il1iII.lIlilIilillll11iil1li1 = iiIlIlilIlIll1l1l1l(lIlill1IIIlli1iII1ill, #{ 59738, 38876, 31250, 75801, 96293, 27832, 11774, 9098, 31230, 80836, 129303, 101680, 12689, 60836 } - 3 + 38 + 32 - 43 + 21 - 10 + 5 - 32 + 14 - 8 + 7 - 15 - 19, #{ 37073, 70137, 113242, 21765, 129309, 86407, 33113, 85980, 105005, 59356, 53236, 100694, 61483, 55175, 85902, 33351, 70969, 133357, 55705, 74121, 116292, 132529 } - 13 - 4 - 47 - 36 - 29 + 17 - 49 + 43 - 48 - 42 - 4 - 18 + 16 + 201) l1iI1Illil1i1il1iII.I1i1IiiIlIIl1II11IiI = iiIlIlilIlIll1l1l1l(lIlill1IIIlli1iII1ill, #{ 129902, 68496, 976, 73113, 19012, 12350, 23326, 93845, 88636, 103236, 52249, 70226, 40074,
This is a VERY VERY VERY small sample, in all there are 40,000 chars.
I understand this is quite an old thread but perhaps I can assist with some information you may not know. This script is in lua created by an older version of the current Luraph. Sold on a multi-purpose website called V3rmillion and sold as a service on the black market. Although the "obfuscated" code was paid, since every script you want obfuscated costs $1 PayPal, I assume their obfuscations are quite worth the price. The pastebin provided does not include the watermark, but I know that it's Luraph because of this side message: http://prntscr.com/k37hin This is a good example of custom bytecode which may sound pretty awesome but in return is just Lua bytecode that uses a lua virtual machine to comprehend what it means. Which is also related to Lua bytecode; using a interpreter to understand what the bytecode means and resulting in a executable code. So practically Luraph uses a custom-made interpreter and custom-made bytecode and uses the interpreter to understand the bytecode then turn it into executable code.
Luraph is an LBI.
Here is the lbi: https://github.com/JustAPerson/lbi/blob/master/src/lbi.lua
It uses custom Bytecode, you can easily find the patterns in the script from the lbi, and the luraph vm. Just replace those, and you get a readable vm.
Deobfuscating the Bytecode is a whole different matter.
There are a few different things you can do to help get rid of obfuscation in code.
1. Use Proper Variable and Function Names
One would be to find and replace all of the different variable and function names with something more distinctive than "I1lili1" and so on. This would allow you to follow the code much easier and also prevent you confusing any variables with each other.
2. Indent the Code
Another would be to look for the 'if', 'while', 'function' and 'end' keywords and then start indenting the code to make it more readable and again easier to follow.
3. Solve the Basic Maths
The above code uses the length function (#) very often as it is using most of the lists as another way to represent normal numbers and prevent people seeing the actual numbers easily. For example:
#{ 10, 372, 67298, 2287, 694, 1, 5039 }
will become:
7
when you perform the length function. If you change all of those lists to actual numbers and then solve the simple addition and subtraction equations after you can get rid of nearly all the numbers.
Of course doing this will take a lot of time but that's the point of obfuscating the code after all. If you don't want to spend a few hours going through all the code getting rid of the obfuscation you can just use this version I prepared earlier: https://pastebin.com/Amtt8UMP I have used all of the above methods to get rid of some of the obfuscation in the code however you will still need to trace through the program to find the outputs from all the functions.
As Egor Skriptunoff commented however, all this piece of code will do most likely is activate a loadstring. This code from the loadstring will also probably be obfuscated so in reality this piece of code it useless to you.
Hope this helps!
I went to create a Archive through Xcode and was presented with
Command failed due to signal: Segmentation fault: 11
#selector(NSDecimalNumberBehaviors.scale)
0 swift 0x00000001067b93ad PrintStackTraceSignalHandler(void*) + 45
1 swift 0x00000001067b8b56 SignalHandler(int) + 790
2 libsystem_platform.dylib 0x00007fffd13feb3a _sigtramp + 26
3 swift 0x0000000106722d51 llvm::MCDwarfLineTableHeader::getFile(llvm::StringRef&, llvm::StringRef&, unsigned int) + 3169
4 swift 0x0000000105ae7c38 llvm::DwarfDebug::endModule() + 1080
5 swift 0x0000000105abe571 llvm::AsmPrinter::doFinalization(llvm::Module&) + 2481
6 swift 0x00000001065edee5 llvm::FPPassManager::doFinalization(llvm::Module&) + 53
7 swift 0x00000001065f789b llvm::legacy::PassManager::run(llvm::Module&) + 1803
8 swift 0x000000010391420a performLLVM(swift::IRGenOptions&, swift::DiagnosticEngine&, llvm::sys::SmartMutex<false>*, llvm::GlobalVariable*, llvm::Module*, llvm::TargetMachine*, llvm::StringRef) + 8234
9 swift 0x0000000103910ccb ThreadEntryPoint(swift::irgen::IRGenerator*, llvm::sys::SmartMutex<false>*, int) + 171
10 swift 0x0000000103910d53 void* std::__1::__thread_proxy<std::__1::tuple<void (*)(swift::irgen::IRGenerator*, llvm::sys::SmartMutex<false>*, int), swift::irgen::IRGenerator*, llvm::sys::SmartMutex<false>*, int> >(void*) + 99
11 libsystem_pthread.dylib 0x00007fffd1408aab _pthread_body + 180
12 libsystem_pthread.dylib 0x00007fffd14089f7 _pthread_body + 0
13 libsystem_pthread.dylib 0x00007fffd14081fd thread_start + 13
The project compiles and runs perfectly fine (Cmd+R)
I've tried:
Clearing the derived data
Rebooting
Searching both Google and SO for any viable options which might match my circumstances.
I've had this before, but have always had some idea of "where" the problem lies, there doesn't seem to be any indication from the stack trace of where to begin to look
The project is (reasonably) large and contains a number of other libraries managed through Carthage, so not easy to post.
I have a "sneaking" suspicion that having opened the project (by mistake) in Xcode 8.3b1 "might" be part of the issue
By following this answer I can make it work, but this is not a long term solution I want to live with.
I know this is long shot and it seems to every question on this has a different cause, but I'd really like to know ANY suggestions that I might look into to solve this issue
I am using Bugsense in my app to get crash reports.
I have a repeating bug with SIGSEGV and no other details about it.
I tried to symbolicate the report but I get this:
0 libobjc.A.dylib 0x33417f78 0x33414000 + 16248
1 CoreFoundation 0x36f651fb 0x36f4d000 + 98811
2 Foundation 0x32c42747 0x32b9e000 + 673607
3 CoreFoundation 0x36fdaad3 0x36f4d000 + 580307
4 CoreFoundation 0x36fda29f 0x36f4d000 + 578207
5 CoreFoundation 0x36fd9045 0x36f4d000 + 573509
6 CoreFoundation 0x36f5c4a5 CFRunLoopRunSpecific + 300
7 CoreFoundation 0x36f5c36d CFRunLoopRunInMode + 104
8 GraphicsServices 0x35123439 GSEventRunModal + 136
9 UIKit 0x35205cd5 UIApplicationMain + 1080
10 English Club 0x00036a2b 0x34000 + 10795
It does not point to any of my classes (In the last line 'English Club' is the name of my app).
Does that mean that this is a bug in apple classes? how can I parse this report to get somthing helpful (like what are the +1234334 numbers in this case etc.
Thank you all
Shani
Does that mean that this is a bug in apple classes?
No.
how can I parse this report to get somthing helpful
Recompile with debug symbols enabled, and run the app in the debugger. Then, if everything was done right, you'll get a symbolicated stack trace.
what are the +1234334 numbers in this case
They're offsets from the beginning of the particular function address - and you're most likely not interested in them.
Your best bet here is to enable zombies and rerun in the debugger and try to reproduce the crash manually. The bug is likely somwhere in your code where you set a delegate that points to one of your objective C objects. For example, see this question which is much like yours: SIGSEGV SEGV_ACCERR Crash Reports - What to do?