过程中出现“分段错误（核心已转储）”

Question

I went with gdb-peda and it said that the error is produced in the inner_loop label. The procedure should do the multiplication of two square matrices

`

matrix_mult:
pushl %ebp        # save the value of ebp on the stack
movl %esp, %ebp   # set up the stack frame 
    
xorl %eax, %eax   # initialize the loop counter
movl 8(%ebp), %ebx # get the pointer to matrix A
movl 12(%ebp), %ecx # get the pointer to matrix B
movl 16(%ebp), %edx # get the pointer to matrix C
movl 20(%ebp), %esi # get the value of N

matrix_loop:
pushl %esi        # save the value of esi on the stack
movl $0, %esi     # initialize the inner loop counter
movl $0, %ebp     # initialize the result for this element

inner_loop:
movl (%ebx,%esi,4), %eax # get the element from matrix A
mull (%ecx,%esi,4) # multiply it by the element from matrix B
addl %eax, %ebp   # add the result to ebp
addl $1, %esi       # increment the loop counter
73: movl 20(%ebp),%edi 
74: cmpl %edi, %esi # compare to N
75: jl inner_loop     # if the loop counter is less than N, jump back to the beginning of the loop

#At this point, ebp contains the result for this element of the matrix
movl %ebp, (%edx) # store the result in the output matrix
addl $4, %edx     # move to the next element in the output matrix
popl %esi         # restore the value of esi
incl %eax           # increment the loop counter
movl 20(%ebp),%edi         
cmpl %edi, %eax # compare to N
jl matrix_loop    # if the loop counter is less than N, jump back to the beginning of the outer loop


popl %ebp
ret 

`

when using gdb-peda it says it breaks between line 73-75 showing something like:

=> 0x565561e4 <inner_loop+11>:  mov    edi,DWORD PTR [ebp+0x14]
   0x565561e7 <inner_loop+14>:  cmp    esi,edi
   0x565561e9 <inner_loop+16>:  jle    0x565561d9 <inner_loop>`

Answer 1

You're asking how to debug this.

An approach is as follows:

1. Segmentation fault is caused by read or write of memory that is not allocated to the process

2. Figure out the effective address of the fault (not the instruction, but the memory reference address). Of course, it will be illegal.

3. Figure out who computed that address, and fix the problem.

While on the one hand, you're looking for a bad (or missing) instructions in code, this can be an iterative process: finding good code that is working on bad data. So, you have to find the code that generated the bad data (another iteration) and repeat until you find what's gone awry.