I'm using LibFuzzer to fuzz test my simple program. I could produce a crash but I cant seem to spot which exact inputs caused the crash.
For example when I run the crash using xxd:
I get 00000000: 0a which I interpret as some sort of input that caused the data?
But is 0a, is this hex or what representation??
Any lead or insights on how to find the input that caused the crash would be really appreciated. TY!
Related
Exception is "Index was outside the bounds of the array." at line :learner.Learn(inputs, outputs).
Ive checked my input and output array so many times, I cant for the life of me work out whats wrong here. Ive also tried it in SVM with the same error.
Reading stack overflow there are a few people who have run into the same error, but I have not been able to implement their fixes to my code.
code
I need to use maxima software to deal with data. I try to read data from a text file constructed as
1 2 3
11 22 33
ect.
Following comands allow for loading data sufficiently.
load(numericalio);
read_matrix("path to the file");
The problem arises when I apply them to a more realistic (larger) data set. In this case the message appears Expression longer than allowed by the configuration setting.
How to overcome this problem? I cannot see any option in configuration menu. I would be grateful for advice.
I ran into the same error message today, at it seems to be related to the size of the output that wxMaxima receives from the Maxima executable.
If you wish to display the output regardless, you can change it in the configuration here:
Edit>Configure>Worksheet>Show long expressions
Note that showing a massive expression or amount of data may dramatically slow the program down, so consider hiding the output (use a $ instead of a ; at the end of your lines) if you don't need to visualize the data.
Not sure if this is a blatantly terrible misunderstanding, but I've been having so trouble with inspecting memory. Here's the following from gdb from examining with x/8w.
0xbffff7a0: 0xb7f9f729 0xb7fd6ff4 0xbffff7d8 0x08048529
0xbffff7b0: 0xb7fd6ff4 0xbffff870 0xbffff7d8 0x00000000
So I'm assuming that 0xb7f9f729 is at 0xbffff7a0, then 0xb7fd6ff4 is at 0xbffff7a4, etc. Could you explain how this works byte wise? Is that 16 bytes from the first memory portion to the next, and each 4 bytes holds it's own word?
I'm having a hard time grasping this memory concept, anyone know a good resource that makes learning it easier?
Yes and yes to both questions.
gdb(1) understands w modifier in your x/8w command as "four byte words", so you are printing 32 bytes in groups of four. gdb(1) just lays them out in short lines with offsets for readability.
I should mention that the exact values printed actually depend on the platform endianness.
You would get similar but probably more understandable layout with x/32.
It's all in the fine manual.
I'm having some issues regarding a conjoint analysis. Excuse me if some of the terms I use are wrong, but it has been some time since I last worked with SPSS - and my teacher was Danish.
Task object
I am to make a series of concept travelpackages (attributes and attribute notes/levels).
This far I've got things under control - I've reduced the number of packages from 81 to 9, with the help of 'orthogonal' design.
These 9 packages have been rated by some people (1-10), on a questionnaire.
Then I've been asked to write a syntax which evaluates my conjoint plan:
CONJOINT PLAN= 'C:\Users\MYNAME\DROBBOXFOLDER\Conjoint_cards.SAV'
/DATA='C:\Users\MYNAME\DROBBOXFOLDER\Respondents.SAV'
/SCORE=Card_1 TO Card_9
/SUBJECT=ID
/FACTORS= SMS Minutter Data Tryghed
/PRINT=ALL
/PLOT=ALL.
However I keep getting this error:
SUBJECT SUBCOMMAND -- Subject variable is not on data file.
Execution of this command stops.
At this point I've been to the dark pages of Google and back for an answer to what I am doing wrong, but nothing so far. The answer is probably staring me in the face. But I will appreciate any help or pointers as to what I'm doing wrong.
Problem solved:
So apparently one shouldn't follow a guide to the letter. My datafile didn't contain a ID, so removing this from my syntax solved the problem.
Taking my first course in assembly language, I am frustrated with cryptic error messages during debugging... I acknowledge that the following information will not be enough to find the cause of the problem (given my limited understanding of the assembly language, ColdFire(MCF5307, M68K family)), but I will gladly take any advice.
...
jsr out_string
Address Error (format 0x04 vector 0x03 fault status 0x1 status reg 0x2700)
I found a similar question on http://forums.freescale.com/freescale/board/message?board.id=CFCOMM&thread.id=271, regarding on ADDRESS ERROR in general.
The answer to the question states that the address error is because the code is "incorrectly" trying to execute on a non-aligned boundary (or accessing non-aligned memory).
So my questions will be:
What does it mean to "incorrectly" trying to execute a non-aligned boundary/memory? If there is an example, it would help a lot
What is non-aligned boundary/memory?
How would you approach fixing this problem, assuming you have little debugging technique(eg. using breakpoints and trace)
First of all, it is possible that isn't the instruction causing the error. Be sure to see if the previous or next instruction could have caused it. However, assuming that exception handlers and debuggers have improved:
An alignment exception is what occurs when, say 32 bit (4 byte) data is retrieved from an address which is not a multiple of 4 bytes. For example, variable x is 32 bits at address 2, then
const1: dc.w someconstant
x: dc.l someotherconstant
Then the instruction
mov.l x, %r0
would cause a data alignment fault on a 68000 (and 68010, IIRC). The 68020 eliminated this restriction and performs the unaligned access, but at the cost of decreased performance. I'm not aware of the jsr (jump to subroutine) instruction requiring alignment, but it's not unreasonable and it's easy to arrange—Before each function, insert the assembly language's macro for alignment:
.align long
func: ...
It has been a long time since I've used a 68K family processor, but I can give you some hints.
Trying to execute on an unaligned boundary means executing code at an odd address. If out_string were at an address with the low bit set for example.
The same holds true for a data access to memory of 2 or 4 byte data. I'm not sure if the Coldfire supports byte access to odd memory addresses, but the other 68K family members did.
The address error occurs on the instruction that causes the error in all cases.
Find out what instruction is there. If the pc matches (or is close) then it is an unaligned execution. If it is a memory access, e.g. move.w d0,(a0), then check to see what address is being read/written, in this case the one pointed at by a0.
I just wanted to add that this is very good stuff to figure out. I program high end medical imaging devices in my day job, but occasionally I need to get down to this level. I have found and fixed more than one COTS OS problem by being able to track down just this sort of problem.