I have the following code:
for (b2Body* b = world->GetBodyList(); b; b = b->GetNext())
{
if (b->GetUserData() != NULL)
{
CCSprite *itemSprite = (CCSprite*)b->GetUserData();
CGSize SpriteSize;
SpriteSize.height = itemSprite.contentSize.height;
SpriteSize.width = itemSprite.contentSize.width;
CGPoint SpritePosition=[itemSprite position];
}
}
Just get the position of sprite, but this program crash sometimes in:
SpriteSize.height = itemSprite.contentSize.height;
and this line:
CGPoint SpritePosition=[itemSprite position];
I am using cocos2d .99.5.
Edit: here is my crash log:
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000f
Crashed Thread: 0
Thread 0 Crashed:
0 libobjc.A.dylib 0x00002666 objc_msgSend_stret + 14
1 ShootTheMonkey 0x0004c066 -[LevelFour ccTouchBegan:withEvent:] (LevelFour.mm:1432)
2 ShootTheMonkey 0x00321bf0 -[CCTouchDispatcher touches:withEvent:withTouchType:] (CCTouchDispatcher.m:238)
3 ShootTheMonkey 0x00322454 -[CCTouchDispatcher touchesBegan:withEvent:] (CCTouchDispatcher.m:305)
4 ShootTheMonkey 0x003240ec -[EAGLView touchesBegan:withEvent:] (EAGLView.m:318)
5 UIKit 0x00053d72 -[UIWindow _sendTouchesForEvent:] + 254
6 UIKit 0x000536fe -[UIWindow sendEvent:] + 74
7 UIKit 0x0004f320 -[UIApplication sendEvent:] + 260
8 UIKit 0x0004ec8c _UIApplicationHandleEvent + 4772
9 GraphicsServices 0x00003b2c PurpleEventCallback + 660
10 CoreFoundation 0x00022d96 CFRunLoopRunSpecific + 2214
11 CoreFoundation 0x000224da CFRunLoopRunInMode + 42
12 GraphicsServices 0x000030d4 GSEventRunModal + 108
13 GraphicsServices 0x00003180 GSEventRun + 56
14 UIKit 0x0000342a -[UIApplication _run] + 374
15 UIKit 0x00001954 UIApplicationMain + 636
16 ShootTheMonkey 0x0000377e main (main.m:13)
17 ShootTheMonkey 0x0000373c start + 32
Since you do not post the crash dump or stack trace, I can only guess. AFAIK there are at least two reasons:
You assign objects of multiple classes to body->SetUserData(). The crash happens when you cast the user data to CCSprite when it's in fact not a CCSprite. Although I doubt this is the case since usually people assign objects of the same class to it.
The second reason is more likely to happen due to the way people usually depend on CCLayer to retain its CCSprite children (rather than explicitly retaining them). When you remove the CCSprites from the parent CCLayer, the latter releases the former and if retain count == 0 (very likely) the CCSprites are released from the heap. But remember that some of b2Bodies are still holding the pointers to these CCSprites through the user data attributes? So what happen when you iterate over all the bodies and try to use the released CCSprites that are still attached to the user data? Crash!
The way to fix this is that you need to remove the bodies when their corresponding sprites are removed from their CCLayer, by either subclassing CCSprite to add an ivar that points to b2Body, or by wrapping both objects (i.e sprite and body) in another class. Then add code to remove the body when the sprite is about to be de-alloc-ed.
Hope this helps. If not, please post more details (crash dump or stack trace).
Well, what we know for sure is the sprite was assigned to userData and it was later deallocated. I see that your assigned sprite was an autoreleased object and more likely it means that out of the scope sprite has received a release massage. To make sure that it is true, try to create sprite as follows: [[CCSprite alloc] initWithSprite:#"apple.png"]; But remember later you must release it.
If it worked for you, use the suggestion that above.
Related
I'm compiling my Qt program with -g -O0 options to get debug symbols. I then run it in lldband it crashes in my code, not the library. But the backtrace I'm getting looks like this:
Target 0: (mastercontrol) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
* frame #0: 0x00007fff5c27f2c2 libsystem_kernel.dylib`__pthread_kill + 10
frame #1: 0x00007fff5c33abf1 libsystem_pthread.dylib`pthread_kill + 284
frame #2: 0x00007fff5c1e96a6 libsystem_c.dylib`abort + 127
frame #3: 0x00007fff593c4641 libc++abi.dylib`abort_message + 231
frame #4: 0x00007fff593c47c7 libc++abi.dylib`default_terminate_handler() + 243
frame #5: 0x00007fff5a977eeb libobjc.A.dylib`_objc_terminate() + 105
frame #6: 0x00007fff593d019e libc++abi.dylib`std::__terminate(void (*)()) + 8
frame #7: 0x00007fff593c3c7e libc++abi.dylib`__cxa_rethrow + 99
frame #8: 0x00007fff5a975e35 libobjc.A.dylib`objc_exception_rethrow + 40
frame #9: 0x00007fff301a05ec CoreFoundation`CFRunLoopRunSpecific + 609
frame #10: 0x00007fff2f3ff1ab HIToolbox`RunCurrentEventLoopInMode + 292
frame #11: 0x00007fff2f3feee5 HIToolbox`ReceiveNextEventCommon + 603
frame #12: 0x00007fff2f3fec76 HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 64
frame #13: 0x00007fff2d79677d AppKit`_DPSNextEvent + 1135
frame #14: 0x00007fff2d79546b AppKit`-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1361
frame #15: 0x00007fff2d78f588 AppKit`-[NSApplication run] + 699
frame #16: 0x000000012264033c libqcocoa.dylib`___lldb_unnamed_symbol693$$libqcocoa.dylib + 2652
frame #17: 0x0000000108a9b75f QtCore`QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 431
frame #18: 0x0000000108a9fb62 QtCore`QCoreApplication::exec() + 130
frame #19: 0x000000010001b20d mastercontrol`main(argc=1, argv=0x00007ffeefbfe2a0) at master_control.cpp:108:10
frame #20: 0x00007fff5c1443d5 libdyld.dylib`start + 1
(lldb)
I.e. the actual site of the crash, which is inside my own code somewhere does not show up.
How do I need to configure my CMake build to get an actual stack trace?
The exception was caught and rethrown in CoreFoundation::CFRunLoopRunSpecific, not in QT.
You have to run the application under a debugger with first-chance-exception enabled in order to break when the exception is thrown first, rather than breaking when it's left uncaught last.
In gdb, that should be catch throw for enabling breakpoint on exception. In lldb use break set -E c++.
I updated my code for Swift 3, run on devices and everything works, but when I Archive project, after cleaning and deleting Delivered Data, I have error "command failed due to signal segmentation fault 11"
My logs
0 swift 0x000000010a5ffb6d PrintStackTraceSignalHandler(void*) + 45
1 swift 0x000000010a5ff5b6 SignalHandler(int) + 470
2 libsystem_platform.dylib 0x00007fff9560152a _sigtramp + 26
3 libsystem_platform.dylib 0x00007fff5825ab50 _sigtramp + 3267728960
4 swift 0x0000000107d29432 swift::CastOptimizer::optimizeUnconditionalCheckedCastAddrInst(swift::UnconditionalCheckedCastAddrInst*) + 1554
5 swift 0x0000000107db144d processFunction(swift::SILFunction&, bool, unsigned int) + 1901
6 swift 0x0000000107db7f9f (anonymous namespace)::ConstantPropagation::run() + 47
7 swift 0x0000000107d4862d swift::SILPassManager::runOneIteration() + 6077
8 swift 0x0000000107d4d7d6 swift::runSILOptimizationPasses(swift::SILModule&) + 3462
9 swift 0x0000000107a153cb performCompile(swift::CompilerInstance&, swift::CompilerInvocation&, llvm::ArrayRef, int&, swift::FrontendObserver*) + 20107
10 swift 0x0000000107a0e265 swift::performFrontend(llvm::ArrayRef, char const*, void*, swift::FrontendObserver*) + 17029
11 swift 0x00000001079cb82d main + 8685
12 libdyld.dylib 0x00007fff8936c5ad start + 1
13 libdyld.dylib 0x000000000000006d start + 1992899265
Stack dump:
and this
While running pass #1059521 SILFunctionTransform "Constant Propagation" on SILFunction "#_TTSg5VSC29UIApplicationLaunchOptionsKeyS_s8Hashable5UIKit_P__CSo8NSObjectS2_S0_10ObjectiveC_Ps9AnyObject____TFs17_dictionaryUpCastu2_Rxs8Hashable0_S_rFGVs10Dictionaryxq__GS0_q0_q1__".
Can someone help or tell, where should I search bug?
In my case I was passing launchOptions as function parameter to another class inside
func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool
After migrating to Swift 3, migrator added cast to match awaited parameter's type, which was of type [NSObject : AnyObject]? (pre Swift 3)
All I had to do is just update my custom function to take [UIApplicationLaunchOptionsKey: Any] as parameter and remove that false cast. Simple as that
I didn't have to compromise any optimization level (which shouldn't even be the last resort for developers, this is definitely not a way how to solve compiler errors/segmentation faults). After removing cast all is working fine with swift's whole module optimization.
I am attempting to create a loop to save me having to type out the code many times. Essentially, I have 60 csv files that I need to alter and save. My code looks as follows:
forvalues i = 0203 0206 : 1112 {
cd "C:\Users\User\Desktop\Data\"
import delimited `i'.csv, varnames(1)
gen time=`i'
keep rssd9017 rssd9010 bhck4074 bhck4079 bhck4093 bhck2170 time
save `i'.dta, replace
}
However, I am getting the error "203.csv" does not exist. It seems to be dropping the leading 0, any way to fix this?
You are asking for a numlist, but in this context 0203, with nothing else said, just looks to Stata like a quirky but acceptable way to write 203: hence your problem.
But do you really have a numlist that is 0203 0206 : 1112?
Try it:
numlist "0203 0206 : 1112"
ret li
The list starts 203 206 209 212 215 218 221 224 227 230 233 236 ...
My wild guess is that you have files, one for each quarter over a period, labelled 0203 for March 2002 through to 1112 for December 2011. In fact you do say that you have times, even though my guess implies 40 files, not 60. If so, that means you won't have a file that is labelled 0215, so this is the wrong way to think in any case.
Here is a better approach. First take the cd out of the loop: you need only do that once!
cd "C:\Users\User\Desktop\Data"
Now find the files that are ????.csv. You need only install fs once.
ssc inst fs
fs ????.csv
foreach f in `r(files)' {
import delimited `f', varnames(1)
gen time = substr("`f'", 1, 4)
keep rssd9017 rssd9010 bhck4074 bhck4079 bhck4093 bhck2170 time
save `time'.dta, replace
}
On my guess, you still need to fix the time to something civilised and you would be better off appending the files, but one problem at a time.
Note that insisting on leading zeros, which you think is the problem here, but is probably a red herring, is written up here.
I'm trying to remove unused blocks from llvm intermediate code.
First, I build a collection of reachable basicblocks, by starting with the entry basicblock and adding all basicblock successors from their terminator instruction:
bbset.insert(bbterm->getSuccessor(i));
After that, I iterate through the unreachable basicblocks and delete them using
DeleteDeadBlock(bb);
from Utils/BasicBlockUtils.cpp
It works, but in some scenarios I get a segfault. Below is the core dump:
opt: /home/user/llvm-3.3.src/lib/Transforms/Utils/BasicBlockUtils.cpp:38: void llvm::DeleteDeadBlock(llvm::BasicBlock*): Assertion `(pred_begin(BB) == pred_end(BB) || BB->getSinglePredecessor() == BB) && "Block is not dead!"' failed.
0 opt 0x0000000001756825 llvm::sys::PrintStackTrace(_IO_FILE*) + 38
1 opt 0x0000000001756aa2
2 opt 0x000000000175651e
3 libpthread.so.0 0x00007fe1fe76dbb0
4 libc.so.6 0x00007fe1fdbaef77 gsignal + 55
5 libc.so.6 0x00007fe1fdbb25e8 abort + 328
6 libc.so.6 0x00007fe1fdba7d43
7 libc.so.6 0x00007fe1fdba7df2
8 opt 0x000000000138b004 llvm::DeleteDeadBlock(llvm::BasicBlock*) + 139
9 opt 0x0000000000d49c2e
10 opt 0x0000000001652942 llvm::FPPassManager::runOnFunction(llvm::Function&) + 290
11 opt 0x0000000001652ab2 llvm::FPPassManager::runOnModule(llvm::Module&) + 84
12 opt 0x0000000001652dd0 llvm::MPPassManager::runOnModule(llvm::Module&) + 502
13 opt 0x00000000016533a0 llvm::PassManagerImpl::run(llvm::Module&) + 244
14 opt 0x00000000016535ab llvm::PassManager::run(llvm::Module&) + 39
15 opt 0x00000000008c6cb6 main + 5698
16 libc.so.6 0x00007fe1fdb99de5 __libc_start_main + 245
17 opt 0x00000000008b8a39
Any ideas what could be the problem?
That's not a segfault, that's an assertion error, and it's telling you the problem: the predecessor list is not empty. You get this assertion error because DeleteDeadBlock verifies that the block you are deleting has no immediate predecessors (other than itself).
However, this test does not mean that the block is alive; for example, in this scenario (assume lines are downward-facing arrows):
entry
/
A B
| |
C D
\ /
E
B and D are both dead, but if you'll try to remove D before B you'll get the assertion since D has a predecessor (which isn't itself).
How to solve this? You can do one of:
Process the blocks in topological order
Remove all predecessors from the block you are about to delete (e.g. by replacing the terminator of all its predecessors with the unreachable instruction)
You can also do that to all the blocks you identify as dead first, and then delete them in arbitrary order
You can use llvm::EliminateUnreachableBlocks. It performs a depth-first-search of basic blocks, starting at the entry block. This helps identify 'live' blocks that would become 'dead' once their 'dead' predecessors are removed.
I am parsing a Collada file for animations. I have it drawn and animated fine but the issue now is how to setup the texture coordinates. I feed it to OpenGL exactly how the collada dae file gives it to me but its mapped completely wrong. The coordinates are range from [0-1].
Do I have to rearrange it?
If I do then please explain to me on how to go about it. I tried using GL_LINEAR and GL_NEAREST but it doesn't solve the problem. Any ideas why?
The models that I am using is the AstroBoy that http://www.wazim.com/Collada_Tutorial_1.htm gives and the Amnesia Servant Grunt.
Based on how you said it turns out to be mapped completely wrong, I'm guessing you haven't taken into account the the texture index values. I had a similar problem as well (although with a difference model). Just like you can have an array of index values so that OpenGL knows which order to draw the verticies, so to does Collada assign UV index values (and normal index values), and, annoyingly, they are never in the same order. Take the following Collada sample for instance:
<source id="Box001-POSITION">
<float_array id="Box001-POSITION-array" count="1008">
-167.172180 -193.451920 11.675772
167.172180 -193.451920 11.675772 .....
....
....
<source id="Box001-Normal0">
<float_array id="Box001-Normal0-array" count="5976">
-0.000000 -0.025202 -0.999682
-0.000000 -0.025202 -0.999682 .....
....
....
<source id="Box001-UV0">
<float_array id="Box001-UV0-array" count="696">
0.000000 0.000000
1.000000 0.000000
0.000000 1.000000 .....
....
....
<triangles count="664" material="_13 - Default">
<input semantic="VERTEX" offset="0" source="#Box001-POSITION"/>
<input semantic="NORMAL" offset="1" source="#Box001-Normal0"/>
<input semantic="TEXCOORD" offset="2" set="0" source="#Box001-UV0"/>
<p> 169 0 171 170 1 172 171 2 173 171 3
173 168 4 170 169 5 171 173 6 175 174
7 176 175 8 177 175 9 177 172 10 174 173 11 175 108 ....
The first three sections indicate the values of the verticies/normals/texture-coords but the final section indicates the index of each value. Notice how the first vertex index is 169, but the first normal index is 0. In fact, the normal indicies are completely normal, they progress as "0..1..2..3" but the indicies for the verticies and textures are all over the place! You have to order your vertex and texture values in the way the Collada file spcifies.
The other way is to write a little program that parses the collada file and rearranges all your vertex, normal and UV values into the right order based on the index values. Then you can just feed your points straight into OpenGL no questions asked. It's up to you of course, which way you want to handle it.
(PS: If you can make a good parser for Collada files, then the 'interleaved-indexing' is actually quite handy, if not though, I find it an over-complication on Collada's part, but you can't really do anything about it.)
No, I advice you to read some basic knowledge of collada .
<triangles count="664" material="_13 - Default">
<input semantic="VERTEX" offset="0" source="#Box001-POSITION"/>
<input semantic="NORMAL" offset="1" source="#Box001-Normal0"/>
<input semantic="TEXCOORD" offset="2" set="0" source="#Box001-UV0"/>
<p> 169 0 171 170 1 172 171 2 173 171 3......
the 169 is the first point index of a triangles,the 0 is the first normal index ,and the 171 is the first texcoord index ,and so on .