I have been trying to understand why I get "SEGMENTATION FAULT" while running a program written in C languagge.
I tried gdb.
This is the message I got:
Program received signal SIGSEGV, Segmentation fault.
0x0016e5e0 in mysql_slave_send_query () from /usr/lib/libmysqlclient.so.16
(gdb) step
Single stepping until exit from function mysql_slave_send_query,
which has no line number information.
Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
The fact is that I get no compiler error/warning messages but the program doesn't work
properly.
Can anyone help me?
My query is:
char query[512];
sprintf(query, "SELECT t1.Art_Acquisto as 'Cod',t2.Des_Articolo as 'Descrizione',t4.Cod_Categoria as 'Cat.',t1.Data_Acquisto as" "'data',t1.Netto_Acquisto as'Importo',t3.Des_Fornitore as 'Fornitore' from "
"Aquisti as t1, Articoli as t2, Fornitori as t3, Categorie as t4 where t1.Art_Acquisto = t2.Cod_Articolo and "
"t1.fornitoreM = t3.codiceF and t4.codiceC = t2.categoriaA and Art_Acquisto ='%s'order by Data_Acquisto;",Cod_Articolo);
Check your arguments to mysql_slave_send_query, especially the length and the proper initialisation/allocation of the other arguments.
"Segmentation fault" means that your program is accessing an invalid memory location during the execution of the function named mysql_slave_send_query.
Therefore this means there is a bug in your C program.
How big is the contents of Cod_Articolo? Your query is nearly 400 characters, and the buffer you're storing it in is only 512 characters - if Cod_Articolo is over 110 characters, your code will break.
If this is the problem, you can prevent it by checking the size of Cod_Articolo before writing it into the query string. Even better, you could calculate the size the query string needs to be, and allocate exactly the right amount.
It's also good practice to use snprintf instead of sprintf, as then you can ensure you don't copy too many characters into the destination string.
Related
I need an invalid opcode with x86 (not x64!) that's exactly one byte in length to overwrite some code in a foreign process. Currently I'm using INT3 (0xCC) but it would be nicer to trap an invalid opcode separately since the foreign process contains a lot of valid INT3.
According to http://ref.x86asm.net/coder32.html, there aren't any in 32-bit mode guaranteed to #UD. Anything that wasn't nailed down has been reused as building material for new extensions.
The ones that exist in 64-bit mode are reserved and not guaranteed to fault on future CPUs; only ud2 is truly guaranteed future-proof. Assuming x86-64 lasts long enough, likely some vendor will make use of that 64-bit-only coding space and stop wasting code-size to also cater to increasingly obsolete 32-bit mode.
If you don't need #UD, you can raise #GP(0) with some privileged instructions in user-space, assuming you're never going to be running in kernel mode.
F4 hlt will always #GP(0) in user-space, not enabled by IOPL, only true CPL=0. (Or #UD if used with a lock prefix). Even if it somehow gets executed in a kernel context, it just stops and waits for the next interrupt, so typically no effect on correctness unless executed with interrupts disabled. (In which case you're stuck until the next NMI).
A similar but worse option is FB sti. But it can execute successfully in a program that's used Linux iopl(), like an X11 server. Unless interrupts were supposed to be disabled, though, that's still not going to lock up your system, it just won't trigger the exception you were looking for. (Unlike cli which could get that CPU stuck, or in al, dx which could do wild IO and even be allowed by ioperm not just iopl, depending on what value is in DX.)
Depending what comes next in memory, 9A callf ptr16:32 might fault on trying to load an invalid value into CS. That value would come from the 2 bytes of machine code 5 and 6 bytes after this one (i.e. after a 32-bit new EIP, since ptr16:32 is stored little-endian). Unlike call rel32 or whatever, it may fault before actually pushing anything and overwriting the current CS:EIP. (But if not, in theory your debugger could simulate popping that far-return address back into CS:EIP after catching the fault.)
Just to be clear, I'm suggesting overwriting a byte with 9A, and leaving the later bytes of machine code unmodified, after checking that the bytes that would be the new CS value are in fact invalid. e.g. by making sure a far call to that address segfaults. Or if this is near the end of a page, and the next is unmapped, it can #PF.
The F0 lock prefix faults with #UD if used on things other than a memory-destination RMW operation, so it can also work if later context would decode as any other instruction. But you can't always use it; you need to check that you aren't creating a valid atomic RMW instruction. e.g. if the ModRM byte was 00 or 01, replacing the opcode with a lock prefix creates a memory-destination add.
#ecm points out that f1 on some CPUs is icebp / int1, but on other CPUs where it isn't, it's undefined but doesn't raise #UD. (http://ref.x86asm.net/coder32.html#xF1)
If the following byte is 0, D4 00 aam 0 is guaranteed to #DE (divide exception). But any other value does immediate 8-bit division of AL.
Depending what byte comes next, CD int n can be used. But not for all following bytes, e.g. int 0x80 won't fault under Linux (unless your kernel is built without CONFIG_IA32_EMULATION). And you might not want some of the other random interrupt numbers. e.g. CD 03 int 3 is pretty much like CC int3.
I have a large equation system to solve. The coefficients are stored in a sparse matrix CM of the dimension 320001 x 320001 elements, of which 18536032 are non-zero. The result vector B is 320001 elements long.
When executing
I=CM\B
Octave Error: SparseMatrix::solve numeric factorization failed
I get the above error message. A brief look into the source code did not give me a clue.
Does anyone know what is causing that error?
BTW: when solving the same problem with a smaller matrix (e.g. 180001x180001) the program runs fine.
Johannes
Octave uses UMFPACK library to solve sparse linear systems. Inspecting the source shows that the error message is due to an error status with a negative value. List of error codes can be found in the user's guide. One of them is related to lack of enough memory:
UMFPACK ERROR out of memory, (-1): Not enough memory. The ANSI C malloc or realloc routine failed.
Hi when i write this piece of code :
module memo(out1);
reg [3:0] mem [2:0] ;
output wire [3:0] out1;
initial
begin
mem[0][3:0]=4'b0000;
mem[1][3:0]=4'b1000;
mem[2][3:0]=4'b1010;
end
assign out1= mem[1];
endmodule
i get the following warnings which make the code unsynthesizable
WARNING:Xst:1780 - Signal mem<2> is never used or assigned. This unconnected signal will be trimmed during the optimization process.
WARNING:Xst:653 - Signal mem<1> is used but never assigned. This sourceless signal will be automatically connected to value 1000.
WARNING:Xst:1780 - Signal > is never used or assigned. This unconnected signal will be trimmed during the optimization process.
Why am i getting these warnings ?
Haven't i assigned the values of mem[0] ,mem[1] and mem[2]!?? Thanks for your help!
Your module has no inputs and a single output -- out1. I'm not totally sure what the point of the module is with respect to your larger system, but you're basically initializing mem, but then only using mem[1]. You could equivalently have a module which just assigns out1 to the value 4'b1000 (mem never changes). So yes -- you did initialize the array, but because you didn't use any of the other values the xilinx tools are optimizing your module during synthesis and "trimming the fat." If you were to simulate this module (say in modelsim) you'd see your initializations just fine. Based on your warnings though I'm not sure why you've come to the conclusion that your code is unsynthesizable. It appears to me that you could definitely synthesize it, but that it's just sort of a weird way to assign a single value to 4'b1000.
With regards to using initial begins to store values in block ram (e.g. to make a ROM) that's fine. I've done that several times without issue. A common use for this is to store coefficients in block ram, which are read out later. That stated the way this module is written there's no way to read anything out of mem anyway.
I know MIPS would get wrong epc register value when it happens at branch delay, and epc = fault_address - 4.
But now, I often get the wrong EPC value which is even NOT in .text segment such as 0xb6000000, what's wrong with the case??
Thanks for your advance..
The CPU does not know anything about the boundaries of the .text region in your program. It simply implements a 2^32 byte address space.
It is possible for an incorrectly programmed jump to go to any address within the 2^32 byte address space. The jump instruction itself will not cause any sort of exception - in fact the MIPS32® Architecture for Programmers Volume II: The MIPS32® Instruction Set explicitly states that jump (J, JR, JALR) instructions do not trigger any exceptions.
When the processor starts executing from the destination of an incorrectly programmed jump, in presumably uninitialized memory, what happens next depends on the contents of that memory. If uninitialized memory is filled with "random" data, that data will be interpreted as instructions which the processor will execute until an illegal instruction is found, or until an instruction triggers some other exception.
I got an "unaligned memory accesses not supported error" and did a Google search for that
but there were no clear explanations.
The whole error message is:
/c:\cuda\include\math_functions_dbl_ptx1.h(1308): Error: Unaligned memory accesses not supported
The following code caused the error:
for (j = low; j <= high; j++)
The variables j and high are declared as int.
This kind of error was encountered before but resolved by itself (I did nothing).
Can anybody explain about this matter?
Theory
On many machines - but not Intel IA32 ones or their relatives - if you want to access a 2-byte quantity (integer), the address must be even, not odd; if you want to access a 4-byte quantity (integer or float) the address must be a multiple of 4 bytes; if you want to access an 8-byte quantity (integer or double), the address must be a multiple of 8 bytes; and so on.
Superficially, then, you have somehow got your code trying dereference a pointer which has bits set in the low-order parts when you should not. For example, one way of forcing the issue (in C) would be:
long l = 0x12345678;
void *v = (char *)&l + 1;
long *lp = v;
l = *lp;
By the time you've gone through the pointer arithmetic, the address in lp is not 4-byte (or 8-byte) aligned; it is off-by-one because of the +1. The last line would give an unaligned memory access pointer.
Practice
Since you have not shown the declarations for your code, we can't be sure what causes the trouble (though you do say j and high are int variables; no comment about low). Indeed, almost independent of the declarations, it seems unlikely that the quoted for loop is the source of the trouble. It may be code close to that, but it probably is not that line.
There is a chance that you have a buffer over-writing problem somewhere and are modifying a pointer by accident, and that modified pointer generates the error. But, since that line does not seem to include any pointers, it is unlikely to be that line that is actually triggering the trouble.