I'm newbie here and iphone app dev.
Sometimes I see this error & app crash on running my app by simulator.
xcode 4.4.1 , Mountain Lion, iOS 5.1 used.
I guess it's running time dependent error because it occurs after running the app a few sec(over 30s) later.
How can I detect and fix this?
thank you for your attention.
hm..I can't upload my capture image
Thread 1
0 0x0eae45e6
7 glDrawElements
8 -[CCTextureAtlas drawNumberOfQuads..
9 -[CCTextureAtlas drawQuads]
10 -[CCSpriteBatchNode draw]
11 -[CCTMXLayer draw]
12 -[CCSpriteBatchNode visit]
13 -[CCNode visit]
14 -[CCNode visit]
15 -[CCNode visit]
16 -[CCDirectorIOS drawScene]
17 -[CCDirectorDisplayLink mainLoop:]
18 CA::Display::DisplayLink::dispatch(...
27 UIApplicationMain
28 main
29 start
editor window error
0xeae45e6: movaps %xmm4, -2472(%ebp) <<<<<
Thread 1: EXC_???(11)(code=0, subcode=0x0)
0xeae45ed: movaps 64(%edi), %xmm4
0xeae45f1: movaps %xmm4, %xmm5
0xeae45f4: mulps %xmm1, %xmm5
0xeae45f7: addps 64(%eax), %xmm5
0xeae45fb: movaps %xmm5, -2456(%ebp)
0xeae4602: movaps %xmm5, %xmm6
I would say it's a memory problem:
Somewhere in your code you could be corrupting memory - check those places where you access arrays (for out of bounds reading), create formatted strings, release objects.
Try using instruments and check memory - maybe you are leaking it very quickly somewhere else.
I was getting this exact EXC_??? (11) error pretty consistently.
In my case it was multithreading coding error - one of the class members accessed on one thread was also modified (init... release...) by another thread. This means that the code was accessing an instance that was already released or completely recreated.
So adding #synchronized where applicable fixed the error.
Goto CCDirector or, CCDirectoriOS whichever you are using.. and just add
#implementation CCDirectorDisplayLink
-(void) mainLoop:(id)sender
{
if(displayLink_)//Crash fix
[self drawScene];
}
It should fix the crash..
This error was cause by having the app installed via other ways other than via xcode and then trying to run using xcode.
I strongly suspect this exception gets raised when you forget to disable vertex attributes that are not part of the current shader.
Try running this function:
// debug
static void PrintAllActiveAttributes()
{
int maxAttribs ;
glGetIntegerv( GL_MAX_VERTEX_ATTRIBS, &maxAttribs ) ;
for( int i = 0 ; i < maxAttribs ; i++ )
{
int enabled ;
glGetVertexAttribiv( i, GL_VERTEX_ATTRIB_ARRAY_ENABLED, &enabled ) ;
if( enabled ) printf( "INDEX %d ENABLED\n", i ) ;
}
}
If you did not disable some attributes (by calling glDisableVertexAttribArray) that were used by a previously bound shader, then those attributes will still be active, even if the currently bound vertex buffer does not use it. I believe this results in some memory OOB exceptions being thrown.
Related
I have seen the good answer to my quesntion from Debugging CodeStubAssembler (CSA) code in V8. howerver,i really cannot understand the point "You can then step through the CSA code as it emits a Turbofan IR graph which the Turbofan backend will then translate to machine code" in upshot one.Can I debug CSA line by line according to the source code in that way?
In order to express my needs more clearly,I use some code examples:
2864 TNode<Smi> CodeStubAssembler::BuildAppendJSArray(ElementsKind kind,
2865 TNode<JSArray> array,
2866 CodeStubArguments* args,
2867 TVariable<IntPtrT>* arg_index,
2868 Label* bailout) {
2869 Comment("BuildAppendJSArray: ", ElementsKindToString(kind));
2870 Label pre_bailout(this);
2871 Label success(this);
2872 TVARIABLE(Smi, var_tagged_length);
The above is the code in CSA,Can I enter 'n' in gdb and then single step from line 2869 to line 2870 ?
Just to be clear,Can I get the following format for debugging CSA code?
[───────────────────────────────────────────────────────────────────────────────────────DISASM───────────────────────────────────────────────────────────────────────────────────────]
0x7f9fc9bcaca5 mov rax, qword ptr [rbp - 0x60]
0x7f9fc9bcaca9 mov rcx, qword ptr fs:[0x28]
0x7f9fc9bcacb2 mov rdx, qword ptr [rbp - 8]
0x7f9fc9bcacb6 cmp rcx, rdx
0x7f9fc9bcacb9 mov qword ptr [rbp - 0xb0], rax
► 0x7f9fc9bcacc0 jne 0x7f9fc9bcacd6
0x7f9fc9bcacc6 mov rax, qword ptr [rbp - 0xb0]
0x7f9fc9bcaccd add rsp, 0xb0
0x7f9fc9bcacd4 pop rbp
0x7f9fc9bcacd5 ret
0x7f9fc9bcacd6 call __stack_chk_fail#plt <0x7f9fcb191dc0>
[───────────────────────────────────────────────────────────────────────────────────────SOURCE───────────────────────────────────────────────────────────────────────────────────────]
457 // static
458 MaybeHandle<Object> Execution::Call(Isolate* isolate, Handle<Object> callable,
459 Handle<Object> receiver, int argc,
460 Handle<Object> argv[]) {
461 return Invoke(isolate, InvokeParams::SetUpForCall(isolate, callable, receiver,
462 argc, argv));
463 }
464
465 MaybeHandle<Object> Execution::CallBuiltin(Isolate* isolate,
466 Handle<JSFunction> builtin,
[───────────────────────────────────────────────────────────────────────────────────────STACK
Yes, you can do that, just like for any other C++ code.
Of course, this code runs as part of mksnapshot, and what it does is it creates (part of) a "builtin" code object that can handle appending elements to JavaScript arrays. Line 2869 will put a comment into the code object's comment section (if you are running with the --code-comments flag), line 2870 will define a label that will be used for conditional jumps later.
So just to be clear, this code does not run when you actually append elements to arrays. At that time, the builtin generated by this code will run, and debugging that requires different techniques (see the other answer).
EDIT to address questions in comments:
If i enter p kind in line 2870,can i get the value of kind? if i enter p ElementsKindToString in this function,can i get the address of function ElementsKindToString?
Yes, of course, this is plain C++. (Also, why do you ask? Just try it!)
how could i break in gdb before the Turbofan backend translate this function to machine code and get the debugging format i posted above.
Run mksnapshot in GDB and set a breakpoint on the line you want, then switch the view mode as desired. (Again, this is regular GDB usage; if you need a GDB tutorial then please search for one, there are plenty on the 'net.)
While you haven't directly asked for it, I have a suspicion that what you really want to do is step through the generated builtins instruction-by-instruction and see the CSA source that was responsible for generating them. That, unfortunately, is not possible, because the builtins and their generators run at different times (and even in different binaries!).
The Vulkan under QML example runs for at most a couple of seconds before crashing with the following error:
libc++abi.dylib: terminating with uncaught exception of type std::__1::system_error: mutex lock failed: Invalid argument
While the animation looks correct during operation, the QML label is not displayed correctly:
I'm running macOS Catalina with MoltenVK 1.1.130 (LunarG Vulkan SDK) and Qt 5.14.0. I've also tried MoltenVK 1.2.131, with the same result. When using MoltenVK with MVK_LOG_LEVEL_INFO enabled, the following message is printed twice every frame:
[mvk-info] vkCreateMacOSSurfaceMVK(): You are not calling this function from the main thread. NSView should only be accessed from the main thread. When using this function outside the main thread, consider passing the CAMetalLayer itself in VkMacOSSurfaceCreateInfoMVK::pView, instead of the NSView.
Question
Does anyone know what could cause this? Is this a bug? Has anyone run this example successfully?
The MVK error message makes it appear a though the Vulkan integration of Qt is broken: Not only is vkCreateMacOSSurfaceMVK called twice every frame, but it also seems to be called from the render thread (not the GUI thread/main thread).
Details
In order to even use Qt with Vulkan, you must compile Qt from source and provide the Vulkan headers. The configuration call I used to compile Qt is:
../qt5/configure -developer-build -skip qtquick3d -skip qtwebengine -opensource -nomake examples -nomake tests -confirm-license -vulkan -I $VULKAN_SDK/../MoltenVK/include -L $VULKAN_SDK/lib
My environment variables are set according to the LunarG documentation:
export VULKAN_SDK="$HOME/SDK/vulkansdk-macos-1.1.130.0/macOS"
export PATH="$VULKAN_SDK/bin:$PATH"
export DYLD_LIBRARY_PATH="$VULKAN_SDK/lib:$DYLD_LIBRARY_PATH"
export VK_ICD_FILENAMES="$VULKAN_SDK/etc/vulkan/icd.d/MoltenVK_icd.json"
export VK_LAYER_PATH="$VULKAN_SDK/etc/vulkan/explicit_layer.d"
export VK_INSTANCE_LAYERS="VK_LAYER_KHRONOS_validation"
export QT_VULKAN_LIB="$VULKAN_SDK/lib/libMoltenVK.dylib"
(Qt requires the QT_VULKAN_LIB to dlopen the library.)
lldb backtrace:
[mvk-info] vkCreateMacOSSurfaceMVK(): You are not calling this function from the main thread. NSView should only be accessed from the main thread. When using this function outside the main thread, consider passing the CAMetalLayer itself in VkMacOSSurfaceCreateInfoMVK::pView, instead of the NSView.
[mvk-info] vkCreateMacOSSurfaceMVK(): You are not calling this function from the main thread. NSView should only be accessed from the main thread. When using this function outside the main thread, consider passing the CAMetalLayer itself in VkMacOSSurfaceCreateInfoMVK::pView, instead of the NSView.
libc++abi.dylib: terminating with uncaught exception of type std::__1::system_error: mutex lock failed: Invalid argument
Process 83453 stopped
* thread #10, name = 'QSGRenderThread', stop reason = signal SIGABRT
frame #0: 0x00007fff648c57fa libsystem_kernel.dylib`__pthread_kill + 10
libsystem_kernel.dylib`__pthread_kill:
-> 0x7fff648c57fa <+10>: jae 0x7fff648c5804 ; <+20>
0x7fff648c57fc <+12>: movq %rax, %rdi
0x7fff648c57ff <+15>: jmp 0x7fff648bfa89 ; cerror_nocancel
0x7fff648c5804 <+20>: retq
Target 0: (main) stopped.
(lldb) frame info
frame #0: 0x00007fff648c57fa libsystem_kernel.dylib`__pthread_kill + 10
(lldb) frame variable
(lldb) bt
* thread #10, name = 'QSGRenderThread', stop reason = signal SIGABRT
* frame #0: 0x00007fff648c57fa libsystem_kernel.dylib`__pthread_kill + 10
frame #1: 0x00007fff64982bc1 libsystem_pthread.dylib`pthread_kill + 432
frame #2: 0x00007fff6484ca1c libsystem_c.dylib`abort + 120
frame #3: 0x00007fff618e6be8 libc++abi.dylib`abort_message + 231
frame #4: 0x00007fff618e6d84 libc++abi.dylib`demangling_terminate_handler() + 238
frame #5: 0x00007fff63412792 libobjc.A.dylib`_objc_terminate() + 104
frame #6: 0x00007fff618f3dc7 libc++abi.dylib`std::__terminate(void (*)()) + 8
frame #7: 0x00007fff618f3d79 libc++abi.dylib`std::terminate() + 41
frame #8: 0x0000000103942439 libQt5Core_debug.5.dylib`qTerminate() at qglobal.cpp:3333:5
frame #9: 0x000000010341f5f8 libQt5Core_debug.5.dylib`QThreadPrivate::start(arg=0x000000011721cfb0) at qthread_unix.cpp:354:9
frame #10: 0x00007fff64982e65 libsystem_pthread.dylib`_pthread_start + 148
frame #11: 0x00007fff6497e83b libsystem_pthread.dylib`thread_start + 15
I've reported the issue: QTBUG-82600
The fix was merged into Qt 5.15.0 beta2. Although the crashes no longer occur, the text remains mangled. The fix for that is postponed until Qt6: QTBUG-83072
I'm currently learning assembly with MSP430.
This simple code should trigger an interrupt for TimerA.
#include "msp430.h" ; #define controlled include file
RSEG CSTACK
RSEG CODE
Reset:
mov.w #WDTPW|WDTHOLD, &WDTCTL ; stop watchdog
mov.w #MC_0|TACLR, &TACTL; stop timer
mov.w #7D0h, &TACCR0; count to 2000
mov.w #CCIE ,&TACCTL0
mov.w #MC_1|TAIE|TASSEL_2, &TACTL; RESET timerA, start it and set clock to VCO
mov.b #BIT0, &P2DIR; output
mov.b #BIT0, &P2OUT;
Main:
mov.w #GIE, SR;
jmp Main;
INTER:
xor.b #BIT0, &P1OUT ; toggle LED
reti
RSEG RESET
DW Reset;
ORG 0xFFF2; address of interrupt
DW INTER
END
But get following error after trying to load code on my MSP:
Error[e104]: Failed to fit all segments into specified ranges. Problem
discovered in segment CODE. Unable to place 1 block(s) (0xfff4 byte(s) total)
in 0x7e0 byte(s) of memory.
The problem occurred while processing the segment placement command
"-P(CODE)CODE=F800-FFDF", where at the moment of placement the
available memory ranges were "CODE:f800-ffdf"
Error while running Linker
I am sure it is some noob error, but can you explain what it is?
Interrupts are not working in inline-assembler of C++(i tried VC++ 10, GCC 4, Digital Mars). Is there any interrupt-equivalent windows free-to-access memory areas? How can i reach system properties and video ram?(can i?)
These i would like to know:
mov ah,06h
mov dl,35h
int 21f //would print '5' on screen but it isnt (works in only pure assembler)
and:
mov ax,1500h
mov ch,97h
int 2f //would get me info for the cache-hit number on DI:SI
Thank you
Win32 applications don't call interrupts, they call system services. There's a number of assembly for Windows tutorials on Iczelion's page.
I'm currently working on hooking ntdll.dll calls via dll injection.
At first, I create thread in existing process via CreateRemoteThread() then I load my dll via LoadLibrary and finally hook calls on PROCESS_ATTACH.
Injection works fine, but then I want to log all registry and file system queries. And the problem is that it doesn't work properly.
I decided to publish code via PasteBin, because piece is pretty big. Here is the link:
http://pastebin.com/39r4Me6B
I'm trying to hook ZwOpenKey, then log key content and then launch "true" function by pointer. Function NOpenKey gets executed, but process stops without any errors.
Does anyone see any issues?
If you use OllyDbg, ZwOpenKey starts with 5 bytes MOV EAX, 77.
You can overwrite these bytes like so JMP _myZwOpenKey then from there you can do whatever with the values on the stack, restore all registers then do a JMP 7C90D5B5 which is address of ZwOpenKey + 5 bytes.
CPU Disasm
Address Hex dump Command Comments
7C90D5AF 90 NOP
7C90D5B0 /$ B8 77000000 MOV EAX,77 ; ntdll.ZwOpenKey(guessed rg1,Arg2,Arg3)
7C90D5B5 |. BA 0003FE7F MOV EDX,7FFE0300
7C90D5BA |. FF12 CALL DWORD PTR DS:[EDX]
7C90D5BC \. C2 0C00 RETN 0C
I usually do these in Assembly that way I don't have to mess around a lot with type casting and all that. Hope this helps.