Search Results

Search found 89 results on 4 pages for 'jmp'.

Page 4/4 | < Previous Page | 1 2 3 4 

• C# properties: How are they instantiated?

  - by Pedery

  Hi! This might be a pretty straightforward question, but I'm trying to understand some of the internal workings of the compilation. Very simply put, imagine an arbitrary object being instantiated. This object is then allocated on the heap. The object has a property of type PointF (which is value type), with a get and a set method. Imagine the get and the set method containing a few calculations for doing their work. How and where (stack/heap) and when is this code instantiated? This is the background for this question: I'm writing get and set methods for an object and these methods need to be accessed very frequently. The get and set code in itself is rather massive so I feared that in a worst case scenario the methods would be instantiated as an object or a value type with all internal code for every access of the property. On the other hand the code is probably instantiated when the main object is created and the CPU is simply told to jmp to the property code start. Anyway, this is what I want to have clarified.

  Read the article

• Sparc Assembly Call corrupts data

  - by Sigge

  I am at the moment working with some assembler code for the Sparc processor family, and i am having some truble with a piece of code.. I think the code and output explains more, but in the short.. When i do a call to the function println my varaibels that i have written to the %fp - 8 memory location is destoryed.. here is my assembler code that i am trying to run !PROCEDURE main .section ".text" .global main .align 4 main: save %sp, -96, %sp L1: set 96, %l0 mov %l0, %o0 call initObject ; nop mov %o0, %l0 mov %l0, %o0 call Test$go ; nop mov %o0, %l0 mov %l0, %o0 call println ; nop L0: ret restore !END main !PROCEDURE Test$go .section ".text" .global Test$go .align 4 Test$go: save %sp, -96, %sp L3: mov %i0, %l0 set 0, %l0 set -8, %l1 add %fp,%l1, %l1 st %l0, [%l1] set 1, %l0 mov %l0, %o0 call println ; nop set -8, %l0 add %fp,%l0, %l0 ld [%l0], %l0 mov %l0, %o0 call println ; nop set 1, %l0 mov %l0, %i0 L2: ret restore !END Test$go Here is the assembler code for the println code .global println .type println,#function println: save %sp,-96,%sp ! block 1 .L193: ! File runtime.c: ! 42 } ! 43 ! 45 /** ! 46 Prints an integer to the standard output stream. ! 47 ! 48 @param i The integer to be printed. ! 49 */ ! 50 void println(int i) { ! 51 printf("%d\n", i); sethi %hi(.L195),%o0 or %o0,%lo(.L195),%o0 call printf mov %i0,%o1 jmp %i7+8 restore This is the out put i get when i run this piece of assembler code 1 67584 1 As u can see, the data that is located at %fp - 8 has been destroyed.. please all feedback is apritiated

  Read the article

• Call 32-bit or 64-bit program from bootloader

  - by user1002358

  There seems to be quite a lot of identical information on the Internet about writing the following 3 bootloaders: Infinite loop jmp $ Print a single character Print "Hello World". This is fantastic, and I've gone through these 3 variations with very little trouble. I'd like to write some 32- or 64-bit code in C and compile it, and call that code from the bootloader... basically a bootloader that, for example, sets the computer up to run some simple numerical simulation. I'll start by listing primes, for example, and then maybe some input/output from the user to maybe compute a Fourier transform. I don't know. I haven't found any information on how to do this, but I can already foresee some problems before I even begin. First of all, compiling a C program compiles it into one of several different files, depending on the target. For Windows, it's a PE file. For Linux, it's a .out file. These files are both quite different. In my instance, the target isn't Windows or Linux, it's just whatever I have written in the bootloader. Secondly, where would the actual code reside? The bootloader is exactly 512 bytes, but the program I write in C will certainly compile to something much larger. It will need to sit on my (virtual) hard disk, probably in some sort of file system (which I haven't even defined!) and I will need to load the information from this file into memory before I can even think about executing it. But from my understanding, all this is many, many orders of magnitude more complex than a 12-line "Hello World" bootloader. So my question is: How do I call a large 32- or 64-bit program (written in C/C++) from my 16-bit bootloader.

  Read the article

• Problem with bootstrap loader and kernel

  - by dboarman-FissureStudios

  We are working on a project to learn how to write a kernel and learn the ins and outs. We have a bootstrap loader written and it appears to work. However we are having a problem with the kernel loading. I'll start with the first part: bootloader.asm: [BITS 16] [ORG 0x0000] ; ; all the stuff in between ; ; the bottom of the bootstrap loader datasector dw 0x0000 cluster dw 0x0000 ImageName db "KERNEL SYS" msgLoading db 0x0D, 0x0A, "Loading Kernel Shell", 0x0D, 0x0A, 0x00 msgCRLF db 0x0D, 0x0A, 0x00 msgProgress db ".", 0x00 msgFailure db 0x0D, 0x0A, "ERROR : Press key to reboot", 0x00 TIMES 510-($-$$) DB 0 DW 0xAA55 ;************************************************************************* The bootloader.asm is too long for the editor without causing it to chug and choke. In addition, the bootloader and kernel do work within bochs as we do get the message "Welcome to our OS". Anyway, the following is what we have for a kernel at this point. kernel.asm: [BITS 16] [ORG 0x0000] [SEGMENT .text] ; code segment mov ax, 0x0100 ; location where kernel is loaded mov ds, ax mov es, ax cli mov ss, ax ; stack segment mov sp, 0xFFFF ; stack pointer at 64k limit sti mov si, strWelcomeMsg ; load message call _disp_str mov ah, 0x00 int 0x16 ; interrupt: await keypress int 0x19 ; interrupt: reboot _disp_str: lodsb ; load next character or al, al ; test for NUL character jz .DONE mov ah, 0x0E ; BIOS teletype mov bh, 0x00 ; display page 0 mov bl, 0x07 ; text attribute int 0x10 ; interrupt: invoke BIOS jmp _disp_str .DONE: ret [SEGMENT .data] ; initialized data segment strWelcomeMsg db "Welcome to our OS", 0x00 [SEGMENT .bss] ; uninitialized data segment Using nasm 2.06rc2 I compile as such: nasm bootloader.asm -o bootloader.bin -f bin nasm kernel.asm -o kernel.sys -f bin We write bootloader.bin to the floppy as such: dd if=bootloader.bin bs=512 count=1 of/dev/fd0 We write kernel.sys to the floppy as such: cp kernel.sys /dev/fd0 As I stated, this works in bochs. But booting from the floppy we get output like so: Loading Kernel Shell ........... ERROR : Press key to reboot Other specifics: OpenSUSE 11.2, GNOME desktop, AMD x64 Any other information I may have missed, feel free to ask. I tried to get everything in here that would be needed. If I need to, I can find a way to get the entire bootloader.asm posted somewhere. We are not really interested in using GRUB either for several reasons. This could change, but we want to see this boot successful before we really consider GRUB.

  Read the article

• MBR Booting from DOS

  - by eflukx

  For a project I would like to invoke the MBR on the first harddisk directly from DOS. I've written a small assembler program that loads the MBR in memory at 0:7c00h an does a far jump to it. I've put my util on a bootable floppy. The disk (HD0, 0x80) i'm trying to boot has a TrueCrypt boot loader on it. It shows up the TrueCrypt screen, but after typing in the password it crashes the system. When I run my little utlility (w00t.com) on a normal WinXP machine it seams to crash immedealty. Apparently I'm forgetting some crucial stuff the BIOS normally does, my guess is it's something trivial. Can someone with better bare-metal DOS and BIOS experience help me out? Heres my code: .MODEL tiny .386 _TEXT SEGMENT USE16 INCLUDE BootDefs.i ORG 100h start: ; http://vxheavens.com/lib/vbw05.html ; Before DOS has booted the BIOS stores the amount of usable lower memory ; in a word located at 0:413h in memory. We going to erase this value because ; we have booted dos before loading the bootsector, and dos is fat (and ugly). ; fake free memory ;push ds ;push 0 ;pop ds ;mov ax, TC_BOOT_LOADER_SEGMENT / 1024 * 16 + TC_BOOT_MEMORY_REQUIRED ;mov word ptr ds:[413h], ax ;ax = memory in K ;pop ds ;lea si, memory_patched_msg ;call print ;mov ax, cs mov ax, 0 mov es, ax ; read first sector to es:7c00h (== cs:7c00) mov dl, 80h mov cl, 1 mov al, 1 mov bx, 7c00h ;load sector to es:bx call read_sectors lea si, mbr_loaded_msg call print lea si, jmp_to_mbr_msg call print ;Set BIOS default values in environment cli mov dl, 80h ;(drive C) xor ax, ax mov ds, ax mov es, ax mov ss, ax mov sp, 0ffffh sti push es push 7c00h retf ;Jump to MBR code at 0:7c00h ; Print string print: xor bx, bx mov ah, 0eh cld @@: lodsb test al, al jz print_end int 10h jmp @B print_end: ret ; Read sectors of the first cylinder read_sectors: mov ch, 0 ; Cylinder mov dh, 0 ; Head ; DL = drive number passed from BIOS mov ah, 2 int 13h jnc read_ok lea si, disk_error_msg call print read_ok: ret memory_patched_msg db 'Memory patched', 13, 10, 7, 0 mbr_loaded_msg db 'MBR loaded', 13, 10, 7, 0 jmp_to_mbr_msg db 'Jumping to MBR code', 13, 10, 7, 0 disk_error_msg db 'Disk error', 13, 10, 7, 0 _TEXT ENDS END start

  Read the article

• Printf in assembler doesn't print

  - by Gaim

  Hi there, I have got a homework to hack program using buffer overflow ( with disassambling, program was written in C++, I haven't got the source code ). I have already managed it but I have a problem. I have to print some message on the screen, so I found out address of printf function, pushed address of "HACKED" and address of "%s" on the stack ( in this order ) and called that function. Called code passed well but nothing had been printed. I have tried to simulate the environment like in other place in the program but there has to be something wrong. Do you have any idea what I am doing wrong that I have no output, please? Thanks a lot EDIT: This program is running on Windows XP SP3 32b, written in C++, Intel asm there is the "hack" code CPU Disasm Address Hex dump Command Comments 0012F9A3 90 NOP ;hack begins 0012F9A4 90 NOP 0012F9A5 90 NOP 0012F9A6 89E5 MOV EBP,ESP 0012F9A8 83EC 7F SUB ESP,7F ;creating a place for working data 0012F9AB 83EC 7F SUB ESP,7F 0012F9AE 31C0 XOR EAX,EAX 0012F9B0 50 PUSH EAX 0012F9B1 50 PUSH EAX 0012F9B2 50 PUSH EAX 0012F9B3 89E8 MOV EAX,EBP 0012F9B5 83E8 09 SUB EAX,9 0012F9B8 BA 1406EDFF MOV EDX,FFED0614 ;address to jump, it is negative because there mustn't be 00 bytes 0012F9BD F7DA NOT EDX 0012F9BF FFE2 JMP EDX ;I have to jump because there are some values overwritten by the program 0012F9C1 90 NOP 0012F9C2 0090 00000000 ADD BYTE PTR DS:[EAX],DL 0012F9C8 90 NOP 0012F9C9 90 NOP 0012F9CA 90 NOP 0012F9CB 90 NOP 0012F9CC 6C INS BYTE PTR ES:[EDI],DX ; I/O command 0012F9CD 65:6E OUTS DX,BYTE PTR GS:[ESI] ; I/O command 0012F9CF 67:74 68 JE SHORT 0012FA3A ; Superfluous address size prefix 0012F9D2 2069 73 AND BYTE PTR DS:[ECX+73],CH 0012F9D5 203439 AND BYTE PTR DS:[EDI+ECX],DH 0012F9D8 34 2C XOR AL,2C 0012F9DA 2066 69 AND BYTE PTR DS:[ESI+69],AH 0012F9DD 72 73 JB SHORT 0012FA52 0012F9DF 74 20 JE SHORT 0012FA01 0012F9E1 3120 XOR DWORD PTR DS:[EAX],ESP 0012F9E3 6C INS BYTE PTR ES:[EDI],DX ; I/O command 0012F9E4 696E 65 7300909 IMUL EBP,DWORD PTR DS:[ESI+65],-6F6FFF8D 0012F9EB 90 NOP 0012F9EC 90 NOP 0012F9ED 90 NOP 0012F9EE 31DB XOR EBX,EBX ; hack continues 0012F9F0 8818 MOV BYTE PTR DS:[EAX],BL ; writing 00 behind word "HACKED" 0012F9F2 83E8 06 SUB EAX,6 0012F9F5 50 PUSH EAX ; address of "HACKED" 0012F9F6 B8 3B8CBEFF MOV EAX,FFBE8C3B 0012F9FB F7D0 NOT EAX 0012F9FD 50 PUSH EAX ; address of "%s" 0012F9FE B8 FFE4BFFF MOV EAX,FFBFE4FF 0012FA03 F7D0 NOT EAX 0012FA05 FFD0 CALL EAX ;address of printf This code is really ugly because I am new in assembler and there mustn't be null bytes because of buffer-overflow bug

  Read the article

• gcc optimization? bug? and its practial implication to project

  - by kumar_m_kiran

  Hi All, My questions are divided into three parts Question 1 Consider the below code, #include <iostream> using namespace std; int main( int argc, char *argv[]) { const int v = 50; int i = 0X7FFFFFFF; cout<<(i + v)<<endl; if ( i + v < i ) { cout<<"Number is negative"<<endl; } else { cout<<"Number is positive"<<endl; } return 0; } No specific compiler optimisation options are used or the O's flag is used. It is basic compilation command g++ -o test main.cpp is used to form the executable. The seemingly very simple code, has odd behaviour in SUSE 64 bit OS, gcc version 4.1.2. The expected output is "Number is negative", instead only in SUSE 64 bit OS, the output would be "Number is positive". After some amount of analysis and doing a 'disass' of the code, I find that the compiler optimises in the below format - Since i is same on both sides of comparison, it cannot be changed in the same expression, remove 'i' from the equation. Now, the comparison leads to if ( v < 0 ), where v is a constant positive, So during compilation itself, the else part cout function address is added to the register. No cmp/jmp instructions can be found. I see that the behaviour is only in gcc 4.1.2 SUSE 10. When tried in AIX 5.1/5.3 and HP IA64, the result is as expected. Is the above optimisation valid? Or, is using the overflow mechanism for int not a valid use case? Question 2 Now when I change the conditional statement from if (i + v < i) to if ( (i + v) < i ) even then, the behaviour is same, this atleast I would personally disagree, since additional braces are provided, I expect the compiler to create a temporary built-in type variable and them compare, thus nullify the optimisation. Question 3 Suppose I have a huge code base, an I migrate my compiler version, such bug/optimisation can cause havoc in my system behaviour. Ofcourse from business perspective, it is very ineffective to test all lines of code again just because of compiler upgradation. I think for all practical purpose, these kinds of error are very difficult to catch (during upgradation) and invariably will be leaked to production site. Can anyone suggest any possible way to ensure to ensure that these kind of bug/optimization does not have any impact on my existing system/code base? PS : When the const for v is removed from the code, then optimization is not done by the compiler. I believe, it is perfectly fine to use overflow mechanism to find if the variable is from MAX - 50 value (in my case).

  Read the article

• grdb not working variables

  - by stupid_idiot

  hi, i know this is kinda retarded but I just can't figure it out. I'm debugging this: xor eax,eax mov ah,[var1] mov al,[var2] call addition stop: jmp stop var1: db 5 var2: db 6 addition: add ah,al ret the numbers that I find on addresses var1 and var2 are 0x0E and 0x07. I know it's not segmented, but that ain't reason for it to do such escapades, because the addition call works just fine. Could you please explain to me where is my mistake? I see the problem, dunno how to fix it yet though. The thing is, for some reason the instruction pointer starts at 0x100 and all the segment registers at 0x1628. To address the instruction the used combination is i guess [cs:ip] (one of the segment registers and the instruction pointer for sure). The offset to var1 is 0x10 (probably because from the begining of the code it's the 0x10th byte in order), i tried to examine the memory and what i got was: 1628:100 8 bytes 1628:108 8 bytes 1628:110 <- wtf? (assume another 8 bytes) 1628:118 ... whatever tricks are there in the memory [cs:var1] points somewhere else than in my code, which is probably where the label .data would usually address ds.... probably.. i don't know what is supposed to be at 1628:10 ok, i found out what caused the assness and wasted me whole fuckin day. the behaviour described above is just correct, the code is fully functional. what i didn't know is that grdb debugger for some reason sets the begining address to 0x100... the sollution is to insert the directive ORG 0x100 on the first line and that's the whole thing. the code was working because instruction pointer has the right address to first instruction and goes one by one, but your assembler doesn't know what effective address will be your program stored at so it pretty much remains relative to first line of the code which means all the variables (if not using label for data section) will remain pointing as if it started at 0x0. which of course wouldn't work with DOS. and grdb apparently emulates some DOS features... sry for the language, thx everyone for effort, hope this will spare someone's time if having the same problem... heheh.. at least now i know the reason why to use .data section :))))

  Read the article

• Need help with BOOST_FOREACH/compiler bug

  - by Jacek Lawrynowicz

  I know that boost or compiler should be last to blame, but I can't see another explanation here. I'm using msvc 2008 SP1 and boost 1.43. In the following code snippet execution never leaves third BOOST_FOREACH loop typedef Graph<unsigned, unsigned>::VertexIterator Iter; Graph<unsigned, unsigned> g; g.createVertex(0x66); // works fine Iter it = g.getVertices().first, end = g.getVertices().second; for(; it != end; ++it) ; // fine std::pair<Iter, Iter> p = g.getVertices(); BOOST_FOREACH(unsigned handle, p) ; // fine unsigned vertex_count = 0; BOOST_FOREACH(unsigned handle, g.getVertices()) vertex_count++; // oops, infinite loop vertex_count = 0; BOOST_FOREACH(unsigned handle, g.getVertices()) vertex_count++; vertex_count = 0; BOOST_FOREACH(unsigned handle, g.getVertices()) vertex_count++; // ... last block repeated 7 times Iterator code: class Iterator : public boost::iterator_facade<Iterator, unsigned const, boost::bidirectional_traversal_tag> { public: Iterator() : list(NULL), handle(INVALID_ELEMENT_HANDLE) {} explicit Iterator(const VectorElementsList &list, unsigned handle = INVALID_ELEMENT_HANDLE) : list(&list), handle(handle) {} friend std::ostream& operator<<(std::ostream &s, const Iterator &it) { s << "[list: " << it.list <<", handle: " << it.handle << "]"; return s; } private: friend class boost::iterator_core_access; void increment() { handle = list->getNext(handle); } void decrement() { handle = list->getPrev(handle); } unsigned const& dereference() const { return handle; } bool equal(Iterator const& other) const { return handle == other.handle && list == other.list; } const VectorElementsList<T> *list; unsigned handle; }; Some ASM fun: vertex_count = 0; BOOST_FOREACH(unsigned handle, g.getVertices()) // initialization 013E1369 mov edi,dword ptr [___defaultmatherr+8 (13E5034h)] // end iterator handle: 0xFFFFFFFF 013E136F mov ebp,dword ptr [esp+0ACh] // begin iterator handle: 0x0 013E1376 lea esi,[esp+0A8h] // begin iterator list pointer 013E137D mov ebx,esi 013E137F nop // forever loop begin 013E1380 cmp ebp,edi 013E1382 jne main+238h (13E1388h) 013E1384 cmp ebx,esi 013E1386 je main+244h (13E1394h) 013E1388 lea eax,[esp+18h] 013E138C push eax // here iterator is incremented in ram 013E138D call boost::iterator_facade<detail::VectorElementsList<Graph<unsigned int,unsigned int>::VertexWrapper>::Iterator,unsigned int const ,boost::bidirectional_traversal_tag,unsigned int const &,int>::operator++ (13E18E0h) 013E1392 jmp main+230h (13E1380h) vertex_count++; // forever loop end It's easy to see that iterator handle is cached in EBP and it never gets incremented despite of a call to iterator operator++() function. I've replaced Itarator implmentation with one deriving from std::iterator and the issue persisted, so this is not iterator_facade fault. This problem exists only on msvc 2008 SP1 x86 and amd64 release builds. Debug builds on msvc 2008 and debug/release builds on msvc 2010 and gcc 4.4 (linux) works fine. Furthermore the BOOST_FOREACH block must be repeaded exacly 10 times. If it's repeaded 9 times, it's all OK. I guess that due to BOOST_FOREACH use of template trickery (const auto_any), compiler assumes that iterator handle is constant and never reads its real value again. I would be very happy to hear that my code is wrong, correct it and move on with BOOST_FOREACH, which I'm very found of (as opposed to BOOST_FOREVER :). May be related to: http://stackoverflow.com/questions/1275852/why-does-boost-foreach-not-work-sometimes-with-c-strings

  Read the article

• Throwing a C++ exception from inside a Linux Signal handler

  - by SoapBox

  As a thought experiment more than anything I am trying to get a C++ exception thrown "from" a linux signal handler for SIGSEGV. (I'm aware this is not a solution to any real world SIGSEGV and should never actually be done, but I thought I would try it out after being asked about it, and now I can't get it out of my head until I figure out how to do it.) Below is the closest I have come, but instead of the signal being caught properly, terminate() is being called as if no try/catch block is available. Anyone know why? Or know a way I can actually get a C++ exception from a signal handler? The code (beware, the self modifying asm limits this to running on x86_64 if you're trying to test it): #include <iostream> #include <stdexcept> #include <signal.h> #include <stdint.h> #include <errno.h> #include <string.h> #include <sys/mman.h> using namespace std; uint64_t oldaddr = 0; void thrower() { cout << "Inside thrower" << endl; throw std::runtime_error("SIGSEGV"); } void segv_handler(int sig, siginfo_t *info, void *pctx) { ucontext_t *context = (ucontext_t *)pctx; cout << "Inside SIGSEGV handler" << endl; oldaddr = context->uc_mcontext.gregs[REG_RIP]; uint32_t pageSize = (uint32_t)sysconf(_SC_PAGESIZE); uint64_t bottomOfOldPage = (oldaddr/pageSize) * pageSize; mprotect((void*)bottomOfOldPage, pageSize*2, PROT_READ|PROT_WRITE|PROT_EXEC); // 48 B8 xx xx xx xx xx xx xx xx = mov rax, xxxx *((uint8_t*)(oldaddr+0)) = 0x48; *((uint8_t*)(oldaddr+1)) = 0xB8; *((int64_t*)(oldaddr+2)) = (int64_t)thrower; // FF E0 = jmp rax *((uint8_t*)(oldaddr+10)) = 0xFF; *((uint8_t*)(oldaddr+11)) = 0xE0; } void func() { try { *(uint32_t*)0x1234 = 123456789; } catch (...) { cout << "caught inside func" << endl; throw; } } int main() { cout << "Top of main" << endl; struct sigaction action, old_action; action.sa_sigaction = segv_handler; sigemptyset(&action.sa_mask); action.sa_flags = SA_SIGINFO | SA_RESTART | SA_NODEFER; if (sigaction(SIGSEGV, &action, &old_action)<0) cerr << "Error setting handler : " << strerror(errno) << endl; try { func(); } catch (std::exception &e) { cout << "Caught : " << e.what() << endl; } cout << "Bottom of main" << endl << endl; } The actual output: Top of main Inside SIGSEGV handler Inside thrower terminate called after throwing an instance of 'std::runtime_error' what(): SIGSEGV Aborted Expected output: Top of main Inside thrower caught inside func Caught : SIGSEGV Bottom of main

  Read the article

• wordexp followed by strcpy = EXC_BAD_ACCESS + sharedlibrary apply-load-rules-all

  - by fyngyrz

  The implication is a memory problem. I have static allocations for these: char akdir[400]; char homedir[400]; This crashes on the first strcpy(): void setuplibfoo() { long ii; double x; wordexp_t result; // This obtains the user's home directory // -------------------------------------- homedir[0]=0; // in case wordexp fails switch (wordexp("~/",&result,0)) { case 0: // Successful. We'll fall into deallocate when done. { strcpy(homedir,result.we_wordv[0]); // <<--- CRASH! strcpy(akdir,homedir); strcat(akdir,"ak-plugins/"); vs_status(akdir); } case WRDE_NOSPACE: // If the error was WRDE_NOSPACE, then { // perhaps part of the result was allocated. wordfree (&result); } default: // all other errors do not require deallocation { break; } } ...additional code clipped.. doesn't get there on crash. This is in a shared library I've written that is linked to my application, also something I've written. In this case, it doesn't get very far, although if it starts, it's fine. ...I've read the wordexp docs several times; they say they allocate new objects, so you just set up that type and call them with the address. The switch error model is right from the wordexp docs: http://www.gnu.org/s/libc/manual/html_mono/libc.html#Wordexp-Example It doesn't always crash. Just sometimes, and just under 10.6. Never under 10.5 I'm building debug mode with XCode 3.1.1, under OSX 10.5.8 it seems to run ok, I've not seen a crash -- under 10.6, it crashes... sometimes. But always with that same exception, and always in the same place. The Google has it that this actually means, somehow, that it's too soon to allocate memory. But all the instances I could find were memory errors on the part of the programmer. Overruns, etc. And I can't find any docs on when it IS safe to allocate memory. Now, the path that expands there is nowhere near 400 characters. it's this (it it completes): /Users/flake/ak-plugins/ and this: /Users/flake/ ...if it doesn't. the strcpy... copies 2nd param to first. Theirs to mine. And it works! under 10.5. :/ So is wordexp broke? Is 10.6 broke? Am I cRaZy? Here's the debugger output: 0x00013446 <+0049> call 0xc98da <dyld_stub_wordexp> 0x0001344b <+0054> test %eax,%eax 0x0001344d <+0056> je 0x13454 <setuplibfoo+63> 0x0001344f <+0058> jmp 0x134da <setuplibfoo+197> 0x00013454 <+0063> mov -0x1c(%ebp),%eax 0x00013457 <+0066> mov (%eax),%eax 0x00013459 <+0068> mov %eax,0x4(%esp) 0x0001345d <+0072> lea 0xb6cc2(%ebx),%eax 0x00013463 <+0078> mov (%eax),%eax 0x00013465 <+0080> mov %eax,(%esp) 0x00013468 <+0083> call 0xc9898 <dyld_stub_strcpy> 0x0001346d <+0088> lea 0xb6cc2(%ebx),%eax <<--CRASH!

  Read the article

• Assembly - Read next sector of a virtual disk

  - by ali

  As any programmer in the world at least once in his/her life, I am trying to create my "revolutionary", the new and only one operating system. :D Well, I am using a virtual emulator (Oracle VM Virtual Box), for which I create a new unknwon operating system, with a vmdk disk. I like vmdk because they are just plain files, so I can paste my boot-loader over the first 512 bytes of the virtual hard disk. Now, I am trying to read the next sector of this virtual disk, on which I would paste a simple kernel that would display a message. I have two questions: Am I reading the second segment (the first -512 bytes- is occupied by the bootloader) correctly? CODE: CitesteDisc: mov bx, 0x8000 ; segment mov es, bx mov bx, 0x0000 ; offset mov ah, 0x02 ; read function mov al, 0x01 ; sectors - this might be wrong, trying to read from hd mov ch, 0x00 ; cylinder mov cl, 0x02 ; sector mov dh, 0x00 ; head mov dl, 0x80 ; drive - trying to read from hd int 0x13 ; disk int mov si, ErrorMessage ; - This will display an error message jc ShowMessage jmp [es:bx] ; buffer Here, I get the error message, after checking CF. However, if I use INT 13, 1 to get last status message, AL is 0 - so no error is saved. Am I pasting my simple kernel in the correct place inside the vmdk? What I do is pasting it after the 512th byte of the file, the first 512 bytes, as I said, are the boot-loader. The file would look like this: BE 45 7C E8 16 00 EB FE B4 0E B7 00 B3 07 CD 10 <- First sector C3 AC 08 C0 74 05 E8 EF FF EB F6 C3 B4 00 B2 80 CD 13 BE 5D 7C 72 F5 BB 00 80 8E C3 BB 00 00 B4 02 B0 06 B5 00 B1 01 B6 00 B2 07 CD 13 BE 4E 7C 72 CF 26 FF 27 57 65 6C 63 6F 6D 65 21 00 52 65 61 64 69 6E 67 20 65 72 72 6F 72 21 00 52 65 73 65 74 74 69 6E 67 20 65 72 72 6F 72 21 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA <- Boot-loader signature B4 0E B0 2E CD 10 EB FE 00 00 00 00 00 00 00 00 <- Start of the second sector 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 So, this is the way I am trying to add the kernel to the second sector. What do you think is wrong with this? Thanks!

  Read the article

• Decompiling a *.DLL to assembly for .net in delphi 4

  - by Lex Dean

  I love my Delphi 4 but at the same time I see the need to talk to windows .net This is a recompiled dll that I found on sourceforge.net/projects/delphinet/ (DelphiNet03.zip) by some nice people that fund the dll from some were. The real answer is to make this dll so that fits into Delphi as true Delphi code, and not a dll clip on. So we can make objects that use dot net in Delphi. Because I’m not an assembly freak, I’m freaking out a little with a wee sweek for help! 1/ How do I link the asm code with the data info at the bottom of this code. Can some one show me which calls to look for to make this link to data. 2/ I need to find the beginning of all the procedures and functions, but I cannot find a ‘RET’ statement. And what line is the beginning statement in this code. 3/ How do I identify were the jump statements go to, put them into Delphi format In this code it looks I can do:- jle 402890h \1000:00402854 7e3a add [eax], al \1000:00402856 0000 …………………………………………….. or ch, [edi+3eh] \1000:0040288d 0a6f3e xrefs first: 1000:00402854 number : 1 \; add [eax], al \1000:00402890 0000 //******************************* jle @@21 \\1000:00402854 7e3a add [eax], al \\1000:00402856 0000 …………………………………………….. or ch, [edi+3eh] \1000:0040288d 0a6f3e xrefs first: 1000:00402854 number : 1 \; @@21 add [eax], al \1000:00402890 0000 Is that a correct conversion. I think a xrefs first: 1000:004021d1 number : 1 is the best to follow 4/ I need a good reference on 8086 up assembly code that I can print out and get to learn properly. I found this asm decomplier of http://www.cronos.cc/ that is so similar to Delphi that it only needs a little more convertion to get it into Delphi asm I think. It’s only taken me 3 hours to get the file into TMemo and to write a few lines to chop the line over in a stream and reload the memo. Help please Email: [email protected] xrefs first: 1000:004041ae number : 1 \\; dd 4190h \\1000:00402000 90410000 dd 00h \\1000:00402004 00000000 dec eax \\1000:00402008 48 add [eax], al \\1000:00402009 0000 add [edx], al \\1000:0040200b 0002 add [eax], al \\1000:0040200d 0000 add [eax-2bffffd2h], al \\1000:0040200f 00802e0000d4 adc al, [eax] \\1000:00402015 1200 add [ecx], al \\1000:00402017 0001 add [eax], al \\1000:00402019 0000 add [eax], al \\1000:0040201b 0000 add [eax], al \\1000:0040201d 0000 add [eax], al \\1000:0040201f 0000 add [eax], al \\1000:00402021 0000 add [eax], al \\1000:00402023 0000 add [eax], al \\1000:00402025 0000 add [eax], al \\1000:00402027 0000 add [eax], al \\1000:00402029 0000 add [eax], al \\1000:0040202b 0000 add [eax], al \\1000:0040202d 0000 add [eax], al \\1000:0040202f 0000 add [eax], al \\1000:00402031 0000 add [eax], al \\1000:00402033 0000 add [eax], al \\1000:00402035 0000 add [eax], al \\1000:00402037 0000 add [eax], al \\1000:00402039 0000 add [eax], al \\1000:0040203b 0000 add [eax], al \\1000:0040203d 0000 add [eax], al \\1000:0040203f 0000 add [eax], al \\1000:00402041 0000 add [eax], al \\1000:00402043 0000 add [eax], al \\1000:00402045 0000 add [eax], al \\1000:00402047 0000 add [eax], al \\1000:00402049 0000 add [eax], al \\1000:0040204b 0000 add [eax], al \\1000:0040204d 0000 add [ebx], dl \\1000:0040204f 0013 xor [eax+eax], al \\1000:00402051 300400 or al, [ecx] \\1000:00402054 0a01 add [eax], al \\1000:00402056 0000 add [eax], eax \\1000:00402058 0100 add [ecx], dl \\1000:0040205a 0011 push cs \\1000:0040205c 0e add al, 50h \\1000:0040205d 0450 mov gs, [ecx+05h] \\1000:0040205f 8e6905 push eax \\1000:00402062 50 mov gs, [ecx+2eh] \\1000:00402063 8e692e add eax, f938h \\1000:00402066 0538f90000 add [ebx], al \\1000:0040206b 0003 jc 402070h \\1000:0040206d 7201 add [eax], al \\1000:0040206f 0000 jo 40209bh \\1000:00402071 7028 add al, [eax] \\1000:00402073 0200 add [edx], cl \\1000:00402075 000a sub eax, 36f0408h \\1000:00402077 2d08046f03 add [eax], al \\1000:0040207c 0000 or ch, [ebx] \\1000:0040207e 0a2b push es \\1000:00402080 06 add al, 6fh \\1000:00402081 046f add al, 00h \\1000:00402083 0400 add [edx], cl \\1000:00402085 000a adc eax, [edi] \\1000:00402087 1307 push ss \\1000:00402089 16 adc ecx, [eax] \\1000:0040208a 1308 cmp cl, cl \\1000:0040208c 38c9 add [eax], al \\1000:0040208e 0000 add [ecx], dl \\1000:00402090 0011 pop es \\1000:00402092 07 adc [eax], ecx \\1000:00402093 1108 callf 056f:060a9a08h \\1000:00402095 9a0a066f05 add [eax], al \\1000:0040209a 0000 or cl, [ebx] \\1000:0040209c 0a0b push es \\1000:0040209e 06 outsd \\1000:0040209f 6f push es \\1000:004020a0 06 add [eax], al \\1000:004020a1 0000 or al, [ebx] \\1000:004020a3 0a03 sub [edx], al \\1000:004020a5 2802 add [eax], al \\1000:004020a7 0000 or bh, [ecx] \\1000:004020a9 0a39 movsd \\1000:004020ab a5 add [eax], al \\1000:004020ac 0000 add [edi], al \\1000:004020ae 0007 mov gs, [ecx+0eh] \\1000:004020b0 8e690e add al, 50h \\1000:004020b3 0450 mov gs, [ecx+40h] \\1000:004020b5 8e6940 cwde \\1000:004020b8 98 add [eax], al \\1000:004020b9 0000 add [edi], dl \\1000:004020bb 0017 or al, 16h \\1000:004020bd 0c16 or eax, 9072b2bh \\1000:004020bf 0d2b2b0709 callf 0000:076f9a09h \\1000:004020c4 9a6f070000 or ch, [edi+08h] \\1000:004020c9 0a6f08 add [eax], al \\1000:004020cc 0000 or ch, [eax+ebx] \\1000:004020ce 0a2c18 push cs \\1000:004020d1 0e add al, 50h \\1000:004020d2 0450 or [edx+d72h], ebx \\1000:004020d4 099a720d0000 jo 402104h \\1000:004020da 7028 or [eax], eax \\1000:004020dc 0900 add [edx], cl \\1000:004020de 000a add dl, cs:[esi] \\1000:004020e0 2e0216 or al, 08h \\1000:004020e3 0c08 sub eax, 90c2b02h \\1000:004020e5 2d022b0c09 pop ss \\1000:004020ea 17 pop eax \\1000:004020eb 58 or eax, 50040e09h \\1000:004020ec 0d090e0450 mov gs, [ecx+32h] \\1000:004020f1 8e6932 int 08h \\1000:004020f4 cd08 sub al, 5ch \\1000:004020f6 2c5c push ss \\1000:004020f8 16 adc eax, [ebx+ebp] \\1000:004020f9 13042b dec esi \\1000:004020fc 4e push cs \\1000:004020fd 0e add al, 50h \\1000:004020fe 0450 adc [edx+ebx*4], eax \\1000:00402100 11049a jc 402112h \\1000:00402103 720d add [eax], al \\1000:00402105 0000 jo 402131h \\1000:00402107 7028 or [eax], eax \\1000:00402109 0900 add [edx], cl \\1000:0040210b 000a xor esi, [esi] \\1000:0040210d 3336 pop es \\1000:0040210f 07 adc [edx+ebx*4], eax \\1000:00402110 11049a outsd \\1000:00402113 6f pop es \\1000:00402114 07 add [eax], al \\1000:00402115 0000 or ch, [edi+0ah] \\1000:00402117 0a6f0a add [eax], al \\1000:0040211a 0000 or dl, [ebx] \\1000:0040211c 0a13 push es \\1000:0040211e 06 add eax, 9a041150h \\1000:0040211f 055011049a sub [ebx], cl \\1000:00402124 280b add [eax], al \\1000:00402126 0000 or dl, [edx] \\1000:00402128 0a12 push es \\1000:0040212a 06 adc al, [c28h] \\1000:0040212b 1205280c0000 xrefs first: 1000:00402107 number : 1 \\; or ch, [edx+eax] \\1000:00402131 0a2c02 sub ebx, [esi] \\1000:00402134 2b1e push cs \\1000:00402136 0e add al, 50h \\1000:00402137 0450 adc [edi+eax], eax \\1000:00402139 110407 adc [edx+ebx*4], eax \\1000:0040213c 11049a outsd \\1000:0040213f 6f pop es \\1000:00402140 07 add [eax], al \\1000:00402141 0000 or ah, [edx+58170411h] \\1000:00402143 0aa211041758 adc eax, [ecx+edx] \\1000:00402149 130411 add al, 0eh \\1000:0040214c 040e add al, 50h \\1000:0040214e 0450 mov gs, [ecx+32h] \\1000:00402150 8e6932 test eax, 58170811h \\1000:00402153 a911081758 adc ecx, [eax] \\1000:00402158 1308 adc [eax], ecx \\1000:0040215a 1108 adc [edi], eax \\1000:0040215c 1107 mov gs, [ecx+3fh] \\1000:0040215e 8e693f sub al, ffh \\1000:00402161 2cff db ff \\1000:00402163 ff jmp [edx] \\1000:00402164 ff2a add [eax], al \\1000:00402166 0000 adc esi, [eax] \\1000:00402168 1330 add eax, 8100h \\1000:0040216a 0500810000 add [edx], al \\1000:0040216f 0002 add [eax], al \\1000:00402171 0000 adc [edx+esi*2], eax \\1000:00402173 110472 xor eax, [eax] \\1000:00402176 3300 add [eax+28h], dh \\1000:00402178 007028 add al, [eax] \\1000:0040217b 0200 add [edx], cl \\1000:0040217d 000a sub al, 09h \\1000:0040217f 2c09 add ebp, [eax] \\1000:00402181 0328 or eax, a0a0000h \\1000:00402183 0d00000a0a sub eax, [edi] \\1000:00402188 2b07 add al, 28h \\1000:0040218a 0428 push cs \\1000:0040218c 0e add [eax], al \\1000:0040218d 0000 or cl, [edx] \\1000:0040218f 0a0a push es \\1000:00402191 06 add eax, f6f1717h \\1000:00402192 0517176f0f add [eax], al \\1000:00402197 0000 or cl, [ebx] \\1000:00402199 0a0b push ss \\1000:0040219b 16 lea eax, [edx] \\1000:0040219c 8d02 add [eax], al \\1000:0040219e 0000 add [esi+ecx], ecx \\1000:004021a0 010c0e add al, 2ch \\1000:004021a3 042c push cs \\1000:004021a5 260e add al, 8eh \\1000:004021a7 048e c160d imul edi, [eax+28dh], d160c01h \\1000:004021a9 69b88d020000010c sub edx, [eax] \\1000:004021b3 2b10 or [ecx], cl \\1000:004021b5 0809 push cs \\1000:004021b7 0e add al, 09h \\1000:004021b8 0409 callf 0000:106f9a09h \\1000:004021ba 9a6f100000 or ah, [edx+d581709h] \\1000:004021bf 0aa20917580d or [esi], ecx \\1000:004021c5 090e add al, 8eh \\1000:004021c7 048e imul esi, [edx], 17202e9h \\1000:004021c9 6932e9027201 add [eax], al \\1000:004021cf 0000 jo 4021dah \\1000:004021d1 7007 db 0f \\1000:004021d3 0f add al, 12h \\1000:004021d4 0412 add ch, [eax] \\1000:004021d6 0228 add [eax], eax \\1000:004021d8 0100 xrefs first: 1000:004021d1 number : 1 \\; add [esi], al \\1000:004021da 0006 pop es \\1000:004021dc 07 or [edi+11h], ch \\1000:004021dd 086f11 add [eax], al \\1000:004021e0 0000 or dl, [ebx] \\1000:004021e2 0a13 add al, 11h \\1000:004021e4 0411 add al, 0eh \\1000:004021e6 040e add al, 6fh \\1000:004021e8 046f adc al, [eax] \\1000:004021ea 1200 add [edx], cl \\1000:004021ec 000a adc eax, [511002bh] \\1000:004021ee 13052b001105 sub al, [eax] \\1000:004021f4 2a00 add [eax], al \\1000:004021f6 0000 adc esi, [eax] \\1000:004021f8 1330 add eax, 4e00h \\1000:004021fa 05004e0000 add [ebx], al \\1000:004021ff 0003 add [eax], al \\1000:00402201 0000 adc [ebx], eax \\1000:00402203 1103 outsd \\1000:00402205 6f adc [eax], al \\1000:00402206 1000 add [edx], cl \\1000:00402208 000a or al, [8db8698eh] \\1000:0040220a 0a058e69b88d add al, [eax] \\1000:00402210 0200 add [ecx], al \\1000:00402212 0001 or edx, [esi] \\1000:00402214 0b16 or al, 2bh \\1000:00402216 0c2b db 0f \\1000:00402218 0f pop es \\1000:00402219 07 or [106f9a08h], al \\1000:0040221a 0805089a6f10 add [eax], al \\1000:00402220 0000 or ah, [edx+c581708h] \\1000:00402222 0aa20817580c or [eb32698eh], al \\1000:00402228 08058e6932eb add al, [esi+eax] \\1000:0040222e 020406 lsl edx, [edx] \\1000:00402231 0f0312 add [eax], ebp \\1000:00402234 0128 add [eax], eax \\1000:00402236 0100 add [esi], al \\1000:00402238 0006 push es \\1000:0040223a 06 add al, 07h \\1000:0040223b 0407 outsd \\1000:0040223d 6f adc eax, [eax] \\1000:0040223e 1300 add [edx], cl \\1000:00402240 000a or eax, 6f050309h \\1000:00402242 0d0903056f adc al, 00h \\1000:00402247 1400 add [edx], cl \\1000:00402249 000a adc eax, [ebx+ebp] \\1000:0040224b 13042b add [ecx], dl \\1000:0040224e 0011 add al, 2ah \\1000:00402250 042a add [eax], al \\1000:00402252 0000 adc esi, [eax] \\1000:00402254 1330 add eax, 7600h \\1000:00402256 0500760000 add [eax+eax], al \\1000:0040225b 000400 add [ecx], dl \\1000:0040225e 0011 add al, 72h \\1000:00402260 0472 xor eax, [eax] \\1000:00402262 3300 add [eax+28h], dh \\1000:00402264 007028 add al, [eax] \\1000:00402267 0200 add [edx], cl \\1000:00402269 000a sub al, 09h \\1000:0040226b 2c09 add ebp, [eax] \\1000:0040226d 0328 or eax, a0a0000h \\1000:0040226f 0d00000a0a sub eax, [edi] \\1000:00402274 2b07 add al, 28h \\1000:00402276 0428 push cs \\1000:00402278 0e add [eax], al \\1000:00402279 0000 or cl, [edx] \\1000:0040227b 0a0a push es \\1000:0040227d 06 add eax, f6f1717h \\1000:0040227e 0517176f0f add [eax], al \\1000:00402283 0000 or cl, [ebx] \\1000:00402285 0a0b push cs \\1000:00402287 0e add eax, 8db8698eh \\1000:00402288 058e69b88d add al, [eax] \\1000:0040228d 0200 add [ecx], al \\1000:0040228f 0001 or al, 16h \\1000:00402291 0c16 or eax, 908102bh \\1000:00402293 0d2b100809 push cs \\1000:00402298 0e add eax, 106f9a09h \\1000:00402299 05099a6f10 add [eax], al \\1000:0040229e 0000 or ah, [edx+d581709h] \\1000:004022a0 0aa20917580d or [esi], ecx \\1000:004022a6 090e add eax, e932698eh \\1000:004022a8 058e6932e9 add cl, [esi] \\1000:004022ad 020e add al, 07h \\1000:004022af 0407 db 0f \\1000:004022b1 0f add eax, 1280212h \\1000:004022b2 0512022801 add [eax], al \\1000:004022b7 0000 push es \\1000:004022b9 06 pop es \\1000:004022ba 07 push cs \\1000:004022bb 0e add al, 08h \\1000:004022bc 0408 outsd \\1000:004022be 6f adc eax, [eax] \\1000:004022bf 1300 add [edx], cl \\1000:004022c1 000a adc eax, [ecx+edx] \\1000:004022c3 130411 add al, 14h \\1000:004022c6 0414 push cs \\1000:004022c8 0e add eax, 146fh \\1000:004022c9 056f140000 or dl, [ebx] \\1000:004022ce 0a13 add eax, 511002bh \\1000:004022d0 052b001105 sub al, [eax] \\1000:004022d5 2a00 add [ebx], dl \\1000:004022d7 0013 xor [eax+eax], al \\1000:004022d9 300400 jbe 4022deh \\1000:004022dc 7600 xrefs first: 1000:004022dc number : 1 \\; add fs:[esi+45h], cl \\1000:004034fc 64004e45 push esp \\1000:00403500 54 dec ecx \\1000:00403501 49 xrefs first: 1000:004034b2 number : 1 \\; outsb \\1000:00403502 6e jbe 403574h \\1000:00403503 766f imul esp, [ebp+43h], 6ch \\1000:00403505 6b65436c popad \\1000:00403509 61 jnc 40357fh \\1000:0040350a 7373 dec ebp \\1000:0040350c 4d jz 403578h \\1000:0040350d 657468 outsd \\1000:00403510 6f add fs:[esi+45h], cl \\1000:00403511 64004e45 push esp \\1000:00403515 54 push ebx \\1000:00403516 53 jz 40355fh \\1000:00403517 657445 outsb \\1000:0040351a 6e jnz 40358ah \\1000:0040351b 756d push esi \\1000:0040351d 56 xrefs first: 1000:004034b7 number : 1 \\; popad \\1000:0040351e 61 insb \\1000:0040351f 6c jnz 403587h \\1000:00403520 7565 add [esi+45h], cl \\1000:00403522 004e45 push esp \\1000:00403525 54 inc edi \\1000:00403526 47 db 65 ;'e' \\1000:00403527 65 xrefs first: 1000:004034be number : 1 \\; db 74 ;'t' \\1000:00403528 74 db 50 ;'p' \\1000:00403529 50 db 72 ;'r' \\1000:0040352a 72 db 6f ;'o' \\1000:0040352b 6f db 70 ;'p' \\1000:0040352c 70 db 65 ;'e' \\1000:0040352d 65 db 72 ;'r' \\1000:0040352e 72 db 74 ;'t' \\1000:0040352f 74 db 79 ;'y' \\1000:00403530 79 db 00 \\1000:00403531 00 db 4e ;'n' \\1000:00403532 4e db 45 ;'e' \\1000:00403533 45 db 54 ;'t' \\1000:00403534 54 db 47 ;'g' \\1000:00403535 47 db 65 ;'e' \\1000:00403536 65 db 74 ;'t' \\1000:00403537 74 db 46 ;'f' \\1000:00403538 46 db 69 ;'i' \\1000:00403539 69 db 65 ;'e' \\1000:0040353a 65 db 6c ;'l' \\1000:0040353b 6c db 64 ;'d' \\1000:0040353c 64 db 00 \\1000:0040353d 00 could not fit the rest in because of Stack overflow limitions

  Read the article

• NSOperationQueue bug with dependencies

  - by Daniel

  I am using NSOperation and NSOperationQueue for performing a sequence of operations, all dependent on each other (2 on 1, 3 on 2, etc...). I set the dependency after I create the operations. I am encountering problems when the queue completes: the program crashes in the _release part of the code, apparently when the NSOperations are getting released. Note that they all get released at the end by the queue, because it is only after the very last one which depends on the second last one, which depends on etc... that they can be released. If I remove any dependency, the code runs fine. If I change waitUntilFinished: to NO, it crashes, if it is YES, it does not. I have isolated the problem to the following code which does not use any of my custom classes. NSOperation by default is a class that does absolutely nothing. Yet, this still crashes when all operations have completed. Therefore, it appears I am not using NSOperationQueue properly but can't see what is wrong. I am running on 10.9 and I have noticed that in general Maverick 10.9 is much more sensitive to these issues than 10.8. I call this method from the main Thread with a Menu item: - (void) testOperations:(id)object { NSOperationQueue* queue = [ [ NSOperationQueue alloc ] init ]; NSMutableArray* array = [ NSMutableArray array ]; for ( int i = 0; i < 10000; i++) [ array addObject: [[[ NSOperation alloc ] init ] autorelease ] ]; for ( int i = 1; i < [ array count ]; i++) [[ array objectAtIndex:i ] addDependency:[array objectAtIndex:i-1]]; // remove this and no crash [ queue addOperations: array waitUntilFinished:NO ]; // Change to YES, no crash [ queue autorelease ]; // or release, it does not make a difference, in fact leaking the memory makes no difference: the code crashes when the queue is removing the NSOperations } This will crash every single time with: bool objc::DenseMapBase , objc_object*, unsigned long, objc::DenseMapInfo, true: (EXC_BAD_ACCESS) The full stack is: #0 0x9104d81b in objc::DenseMapBase<objc::DenseMap<objc_object*, unsigned long, true, objc::DenseMapInfo<objc_object*> >, objc_object*, unsigned long, objc::DenseMapInfo<objc_object*>, true>::find(objc_object* const&) () #1 0x910384e3 in _objc_rootReleaseWasZero () #2 0x9104d5d9 in -[NSObject release] () #3 0x99e41224 in CFRelease () #4 0x99e56277 in -[__NSArrayM dealloc] () #5 0x9104d5ef in -[NSObject release] () #6 0x97f62b22 in -[__NSOperationInternal dealloc] () #7 0x9104d5ef in -[NSObject release] () #8 0x97f62ac8 in -[NSOperation dealloc] () #9 0x9104d5ef in -[NSObject release] () #10 0x99e41224 in CFRelease () #11 0x99e56277 in -[__NSArrayM dealloc] () #12 0x9104d5ef in -[NSObject release] () #13 0x97f62b22 in -[__NSOperationInternal dealloc] () #14 0x9104d5ef in -[NSObject release] () #15 0x97f62ac8 in -[NSOperation dealloc] () #16 0x9104d5ef in -[NSObject release] () #17 0x99e41224 in CFRelease () #18 0x99e56277 in -[__NSArrayM dealloc] () #19 0x9104d5ef in -[NSObject release] () #20 0x97f62b22 in -[__NSOperationInternal dealloc] () #21 0x9104d5ef in -[NSObject release] () #22 0x97f62ac8 in -[NSOperation dealloc] () #23 0x9104d5ef in -[NSObject release] () #24 0x99e41224 in CFRelease () #25 0x99e56277 in -[__NSArrayM dealloc] () #26 0x9104d5ef in -[NSObject release] () #27 0x97f62b22 in -[__NSOperationInternal dealloc] () #28 0x9104d5ef in -[NSObject release] () #29 0x97f62ac8 in -[NSOperation dealloc] () #30 0x9104d5ef in -[NSObject release] () #31 0x99e41224 in CFRelease () #32 0x99e56277 in -[__NSArrayM dealloc] () #33 0x9104d5ef in -[NSObject release] () #34 0x97f62b22 in -[__NSOperationInternal dealloc] () #35 0x9104d5ef in -[NSObject release] () #36 0x97f62ac8 in -[NSOperation dealloc] () #37 0x9104d5ef in -[NSObject release] () #38 0x99e41224 in CFRelease () #39 0x99e56277 in -[__NSArrayM dealloc] () #40 0x9104d5ef in -[NSObject release] () #41 0x97f62b22 in -[__NSOperationInternal dealloc] () #42 0x9104d5ef in -[NSObject release] () #43 0x97f62ac8 in -[NSOperation dealloc] () #44 0x9104d5ef in -[NSObject release] () #45 0x99e41224 in CFRelease () #46 0x99e56277 in -[__NSArrayM dealloc] () #47 0x9104d5ef in -[NSObject release] () #48 0x97f62b22 in -[__NSOperationInternal dealloc] () #49 0x9104d5ef in -[NSObject release] () #50 0x97f62ac8 in -[NSOperation dealloc] () #10722 0x9104d5ef in -[NSObject release] () #10723 0x97f62b22 in -[__NSOperationInternal dealloc] () #10724 0x9104d5ef in -[NSObject release] () #10725 0x97f62ac8 in -[NSOperation dealloc] () #10726 0x9104d5ef in -[NSObject release] () #10727 0x99e41224 in CFRelease () #10728 0x99e56277 in -[__NSArrayM dealloc] () #10729 0x9104d5ef in -[NSObject release] () #10730 0x97f62b22 in -[__NSOperationInternal dealloc] () #10731 0x9104d5ef in -[NSObject release] () #10732 0x97f62ac8 in -[NSOperation dealloc] () #10733 0x9104d5ef in -[NSObject release] () #10734 0x99e41224 in CFRelease () #10735 0x99e56277 in -[__NSArrayM dealloc] () #10736 0x9104d5ef in -[NSObject release] () #10737 0x97f62b22 in -[__NSOperationInternal dealloc] () #10738 0x9104d5ef in -[NSObject release] () #10739 0x97f62ac8 in -[NSOperation dealloc] () #10740 0x9104d5ef in -[NSObject release] () #10741 0x99e41224 in CFRelease () #10742 0x99e56277 in -[__NSArrayM dealloc] () #10743 0x9104d5ef in -[NSObject release] () #10744 0x97f62b22 in -[__NSOperationInternal dealloc] () #10745 0x9104d5ef in -[NSObject release] () #10746 0x97f62ac8 in -[NSOperation dealloc] () #10747 0x9104d5ef in -[NSObject release] () #10748 0x99e41224 in CFRelease () #10749 0x99e56277 in -[__NSArrayM dealloc] () #10750 0x9104d5ef in -[NSObject release] () #10751 0x97f62b22 in -[__NSOperationInternal dealloc] () #10752 0x9104d5ef in -[NSObject release] () #10753 0x97f62ac8 in -[NSOperation dealloc] () #10754 0x9104d5ef in -[NSObject release] () #10755 0x99e41224 in CFRelease () #10756 0x99e56277 in -[__NSArrayM dealloc] () #10757 0x9104d5ef in -[NSObject release] () #10758 0x97f62b22 in -[__NSOperationInternal dealloc] () #10759 0x9104d5ef in -[NSObject release] () #10760 0x97f62ac8 in -[NSOperation dealloc] () #10761 0x9104d5ef in -[NSObject release] () #10762 0x99e41224 in CFRelease () #10763 0x99e56277 in -[__NSArrayM dealloc] () #10764 0x9104d5ef in -[NSObject release] () #10765 0x97f62b22 in -[__NSOperationInternal dealloc] () #10766 0x9104d5ef in -[NSObject release] () #10767 0x97f62ac8 in -[NSOperation dealloc] () #10768 0x9104d5ef in -[NSObject release] () #10769 0x99e41224 in CFRelease () #10770 0x99e56277 in -[__NSArrayM dealloc] () #10771 0x9104d5ef in -[NSObject release] () #10772 0x97f62b22 in -[__NSOperationInternal dealloc] () #10773 0x9104d5ef in -[NSObject release] () #10774 0x97f62ac8 in -[NSOperation dealloc] () #10775 0x9104d5ef in -[NSObject release] () #10776 0x99e41224 in CFRelease () #10777 0x99e56277 in -[__NSArrayM dealloc] () #10778 0x9104d5ef in -[NSObject release] () #10779 0x97f62b22 in -[__NSOperationInternal dealloc] () #10780 0x9104d5ef in -[NSObject release] () #10781 0x97f62ac8 in -[NSOperation dealloc] () #10782 0x9104d5ef in -[NSObject release] () #10783 0x99e41224 in CFRelease () #10784 0x99e56277 in -[__NSArrayM dealloc] () #10785 0x9104d5ef in -[NSObject release] () #10786 0x97f62b22 in -[__NSOperationInternal dealloc] () #10787 0x9104d5ef in -[NSObject release] () #10788 0x97f62ac8 in -[NSOperation dealloc] () #10789 0x9104d5ef in -[NSObject release] () #10790 0x99e41224 in CFRelease () #10791 0x99e56277 in -[__NSArrayM dealloc] () #10792 0x9104d5ef in -[NSObject release] () #10793 0x97f62b22 in -[__NSOperationInternal dealloc] () #10794 0x9104d5ef in -[NSObject release] () #10795 0x97f62ac8 in -[NSOperation dealloc] () #10796 0x9104d5ef in -[NSObject release] () #10797 0x99e41224 in CFRelease () #10798 0x99e56277 in -[__NSArrayM dealloc] () #10799 0x9104d5ef in -[NSObject release] () #10800 0x97f62b22 in -[__NSOperationInternal dealloc] () #10801 0x9104d5ef in -[NSObject release] () #10802 0x97f62ac8 in -[NSOperation dealloc] () #10803 0x9104d5ef in -[NSObject release] () #10804 0x99e41224 in CFRelease () #10805 0x99e56277 in -[__NSArrayM dealloc] () #10806 0x9104d5ef in -[NSObject release] () #10807 0x97f62b22 in -[__NSOperationInternal dealloc] () #10808 0x9104d5ef in -[NSObject release] () #10809 0x97f62ac8 in -[NSOperation dealloc] () #10810 0x9104d5ef in -[NSObject release] () #10811 0x99e41224 in CFRelease () #10812 0x99e56277 in -[__NSArrayM dealloc] () #10813 0x9104d5ef in -[NSObject release] () #10814 0x97f62b22 in -[__NSOperationInternal dealloc] () #10815 0x9104d5ef in -[NSObject release] () #10816 0x97f62ac8 in -[NSOperation dealloc] () #10817 0x9104d5ef in -[NSObject release] () #10818 0x99e41224 in CFRelease () #10819 0x99e56277 in -[__NSArrayM dealloc] () #10820 0x9104d5ef in -[NSObject release] () #10821 0x97f62b22 in -[__NSOperationInternal dealloc] () #10822 0x9104d5ef in -[NSObject release] () #10823 0x97f62ac8 in -[NSOperation dealloc] () #10824 0x9104d5ef in -[NSObject release] () #10825 0x99e41224 in CFRelease () #10826 0x99e56277 in -[__NSArrayM dealloc] () #10827 0x9104d5ef in -[NSObject release] () #10828 0x97f62b22 in -[__NSOperationInternal dealloc] () #10829 0x9104d5ef in -[NSObject release] () #10830 0x97f62ac8 in -[NSOperation dealloc] () #10831 0x9104d5ef in -[NSObject release] () #10832 0x99e41224 in CFRelease () #10833 0x99e56277 in -[__NSArrayM dealloc] () #10834 0x9104d5ef in -[NSObject release] () #10835 0x97f62b22 in -[__NSOperationInternal dealloc] () #10836 0x9104d5ef in -[NSObject release] () #10837 0x97f62ac8 in -[NSOperation dealloc] () #10838 0x9104d5ef in -[NSObject release] () #10839 0x99e41224 in CFRelease () #10840 0x99e56277 in -[__NSArrayM dealloc] () #10841 0x9104d5ef in -[NSObject release] () #10842 0x97f62b22 in -[__NSOperationInternal dealloc] () #10843 0x9104d5ef in -[NSObject release] () #10844 0x97f62ac8 in -[NSOperation dealloc] () #10845 0x9104d5ef in -[NSObject release] () #10846 0x99e41224 in CFRelease () #10847 0x99e56277 in -[__NSArrayM dealloc] () #10848 0x9104d5ef in -[NSObject release] () #10849 0x97f62b22 in -[__NSOperationInternal dealloc] () #10850 0x9104d5ef in -[NSObject release] () #10851 0x97f62ac8 in -[NSOperation dealloc] () #10852 0x9104d5ef in -[NSObject release] () #10853 0x99e41224 in CFRelease () #10854 0x99e56277 in -[__NSArrayM dealloc] () #10855 0x9104d5ef in -[NSObject release] () #10856 0x97f62b22 in -[__NSOperationInternal dealloc] () #10857 0x9104d5ef in -[NSObject release] () #10858 0x97f62ac8 in -[NSOperation dealloc] () #10859 0x9104d5ef in -[NSObject release] () #10860 0x99e41224 in CFRelease () #10861 0x99e56277 in -[__NSArrayM dealloc] () #10862 0x9104d5ef in -[NSObject release] () #10863 0x97f62b22 in -[__NSOperationInternal dealloc] () #10864 0x9104d5ef in -[NSObject release] () #10865 0x97f62ac8 in -[NSOperation dealloc] () #10866 0x9104d5ef in -[NSObject release] () #10867 0x99e41224 in CFRelease () #10868 0x99e56277 in -[__NSArrayM dealloc] () #10869 0x9104d5ef in -[NSObject release] () #10870 0x97f62b22 in -[__NSOperationInternal dealloc] () #10871 0x9104d5ef in -[NSObject release] () #10872 0x97f62ac8 in -[NSOperation dealloc] () #10873 0x9104d5ef in -[NSObject release] () #10874 0x99e41224 in CFRelease () #10875 0x99e56277 in -[__NSArrayM dealloc] () #10876 0x9104d5ef in -[NSObject release] () #10877 0x97f62b22 in -[__NSOperationInternal dealloc] () #10878 0x9104d5ef in -[NSObject release] () #10879 0x97f62ac8 in -[NSOperation dealloc] () #10880 0x9104d5ef in -[NSObject release] () #10881 0x99e41224 in CFRelease () #10882 0x99e56277 in -[__NSArrayM dealloc] () #10883 0x9104d5ef in -[NSObject release] () #10884 0x97f62b22 in -[__NSOperationInternal dealloc] () #10885 0x9104d5ef in -[NSObject release] () #10886 0x97f62ac8 in -[NSOperation dealloc] () #10887 0x9104d5ef in -[NSObject release] () #10888 0x99e41224 in CFRelease () #10889 0x99e56277 in -[__NSArrayM dealloc] () #10890 0x9104d5ef in -[NSObject release] () #10891 0x97f62b22 in -[__NSOperationInternal dealloc] () #10892 0x9104d5ef in -[NSObject release] () #10893 0x97f62ac8 in -[NSOperation dealloc] () #10894 0x9104d5ef in -[NSObject release] () #10895 0x99e41224 in CFRelease () #10896 0x99e56277 in -[__NSArrayM dealloc] () #10897 0x9104d5ef in -[NSObject release] () #10898 0x97f62b22 in -[__NSOperationInternal dealloc] () #10899 0x9104d5ef in -[NSObject release] () #10900 0x97f62ac8 in -[NSOperation dealloc] () #10901 0x9104d5ef in -[NSObject release] () #10902 0x99e41224 in CFRelease () #10903 0x99e56277 in -[__NSArrayM dealloc] () #10904 0x9104d5ef in -[NSObject release] () #10905 0x97f62b22 in -[__NSOperationInternal dealloc] () #10906 0x9104d5ef in -[NSObject release] () #10907 0x97f62ac8 in -[NSOperation dealloc] () #10908 0x9104d5ef in -[NSObject release] () #10909 0x99e41224 in CFRelease () #10910 0x99e56277 in -[__NSArrayM dealloc] () #10911 0x9104d5ef in -[NSObject release] () #10912 0x97f62b22 in -[__NSOperationInternal dealloc] () #10913 0x9104d5ef in -[NSObject release] () #10914 0x97f62ac8 in -[NSOperation dealloc] () #10915 0x9104d5ef in -[NSObject release] () #10916 0x97f49cca in __NSOQSchedule_f () #10917 0x9c1c9e21 in _dispatch_async_redirect_invoke () #10918 0x9c1c53a6 in _dispatch_client_callout () #10919 0x9c1c7467 in _dispatch_root_queue_drain () #10920 0x9c1c8732 in _dispatch_worker_thread2 () #10921 0x960c2dab in _pthread_wqthread () The full crash context is (bold for crash line): libobjc.A.dylib`objc::DenseMapBase<objc::DenseMap<objc_object*, unsigned long, true, objc::DenseMapInfo<objc_object*> >, objc_object*, unsigned long, objc::DenseMapInfo<objc_object*>, true>::find(objc_object* const&): 0x9104d800: pushl %ebp 0x9104d801: movl %esp, %ebp 0x9104d803: pushl %esi 0x9104d804: subl $20, %esp 0x9104d807: leal -8(%ebp), %eax 0x9104d80a: movl %eax, 8(%esp) 0x9104d80e: movl 16(%ebp), %eax 0x9104d811: movl %eax, 4(%esp) 0x9104d815: movl 12(%ebp), %esi 0x9104d818: movl %esi, (%esp) **0x9104d81b: calll 0x9104d9b6 ; bool objc::DenseMapBase<objc::DenseMap<objc_object*, unsigned long, true, objc::DenseMapInfo<objc_object*> >, objc_object*, unsigned long, objc::DenseMapInfo<objc_object*>, true>::LookupBucketFor<objc_object*>(objc_object* const&, std::__1::pair<objc_object*, unsigned long> const*&) const** 0x9104d820: movl 12(%esi), %ecx 0x9104d823: shll $3, %ecx 0x9104d826: addl (%esi), %ecx 0x9104d828: movl 8(%ebp), %edx 0x9104d82b: testb %al, %al 0x9104d82d: je 0x9104d836 ; objc::DenseMapBase<objc::DenseMap<objc_object*, unsigned long, true, objc::DenseMapInfo<objc_object*> >, objc_object*, unsigned long, objc::DenseMapInfo<objc_object*>, true>::find(objc_object* const&) + 54 0x9104d82f: movl -8(%ebp), %eax 0x9104d832: movl %eax, (%edx) 0x9104d834: jmp 0x9104d838 ; objc::DenseMapBase<objc::DenseMap<objc_object*, unsigned long, true, objc::DenseMapInfo<objc_object*> >, objc_object*, unsigned long, objc::DenseMapInfo<objc_object*>, true>::find(objc_object* const&) + 56 0x9104d836: movl %ecx, (%edx) 0x9104d838: movl %ecx, 4(%edx) 0x9104d83b: addl $20, %esp 0x9104d83e: popl %esi 0x9104d83f: popl %ebp 0x9104d840: ret $4 0x9104d843: nop I tried using a pre-created queue, this makes no difference. Apparently, with dependencies, this code is a problem with XCode 5.0, 32-bit. Edit: In fact, I can isolate the problem much further. An empty Cocoa Application project in XCOde 5.0 on 10.9 with ARC on and a single method will crash. If it does not on your computer, increase 4269 to anything bigger: - (void)applicationDidFinishLaunching:(NSNotification *)aNotification { NSOperationQueue* aQueue = [[ NSOperationQueue alloc ] init ]; NSMutableArray* array = [ NSMutableArray array ]; for ( int i = 0; i < 4269; i++) [ array addObject: [ [NSOperation alloc ] init ]]; for ( int i = 1; i < [ array count ]; i++) [[ array objectAtIndex:i ] addDependency:[array objectAtIndex:i-1]]; [ aQueue addOperations: array waitUntilFinished:NO ]; }

  Read the article

< Previous Page | 1 2 3 4