The same program with sam input sometimes works, sometimes not

Hello,
I complied my c++ code after that I had an output
However even if I put same data, it sometimes work and sometimes I am getting killed completed message without no error
The inputs are exactly same and I have no idea why I al getting killed completed message

My codes are here: https://github.com/michelemancusi/libtrevisan
Do you have any idea?
Best
So you've given up using your previous implementation then?
https://www.cplusplus.com/forum/general/275078/

> I complied my c++ code after that I had an output
Yeah, the code in the most recent link is C, not C++.


P.S. If you have a segmentation fault after the input of the data, try to change sizeof(bool) with sizeof(int) in lines 191 and 197 of file extractor.c

Did you do this?
yeah of course I did it
but still it is sometimes work but but sometiles when it is working, it gives a message like killed completely (killedall terminatied I odnt remember exactly) and still no error

P.S: I didnt give up and I al still trying but I should do something so I found that and sorry yes it is c not c++ just confused with other codes
Last edited on
Ok it is related to my memory/ram I increased my swap file so it is better now
However it is very strange I have 8 gb ram and now 20 gb swap file but the code is not suficient more than 60000 character input file ...
You should not be OOM'ing on 60K characters, so it can't be your swap file. What is the exact error you get? OS kernel version and the error code you get would be fantastic.
Hello, I don't have any error. But I am getting "killed completed " after a long time

Run a terminal multiplexor (Tmux works) and run top\htop along side your application. If somehow you really are running out of RAM, you'll be able to see it there. Intermittent behavior like this fits with an out of memory issue, but you're using such a small input that without compiling it myself I don't believe it. Are your running this in the same context everytime? Or doing anything SSSD might not like?
You're going out of range on your array's, 'trevisan.c' is a mess dude. For example, 'galois_log_tables' is declared as a one dimensional array with 33 elements, yet you address it as if it were a two dimensional array constantly. The dimensions in an array are an illusion to help you, when you call galois_log_tables[w][j] for example, the compiler is multiplying 'w*j' and addressing that address space as if it were in the array; DMA means the program doesn't care whether it actually is or not but your OS sure as heck does. This WILL lead to undefined behavior and frequent crashing.
I am now running with tmux and also top
And my program is always at the top and cpu is 100%
Btw, I am using dual operation system and so ubuntu has small part. I do not know it affect a lot or not but maybe this is why I am suffering from memory
And the program is extractor. I mean for each character it is calcutating min entropy again and again for the error rate...I am not running just a simple file program...

Thanks you very much for the answer
So what do you recommand. I need to run this code and I am not expert in c
I can write some thing but definetely I am not the expert for this language for solving this kind of problems

For bigger entropy values, it is ok but this time quality of output is really decreasing... :(
The problem is with your arrays, you neeed better bounds checking. I'm on a bus right now I'll see if i find more time to give better advice later.
Thanks a lot, I will also look something...
This actually doesn't compile, what is 'M_E' supposed to be?
really ? I just use thos line for compiling : gcc extractor.c -lm
It's non-standard (at least the basic standard) to have macros like M_PI and M_E defined in math.h, but implementations can have them. In linux you need to define _XOPEN_SOURCE >= 500 to have them defined.

1
2
#define _XOPEN_SOURCE 500
#include <math.h> 

Otherwise, just define e yourself

 
#define M_E 2.7182818284590452 

Are you saying for extractor. c and for the first line
I was mostly talking to Computergeek01.
Since it already compiles for you there's no point adding that define.
It won't magically make this terrible code work for you.
For those who need to add it, you would place it before the includes.
So I finally got this to compile and my original suspicion is correct, you are falling out of bounds in your arrays. You need to completely overhaul "trevisan.c". I did some reading on this topic, but considering what I found was a Comp Sci 600 paper and I only made it to my bachelors, I doubt I'm qualified to help with the core material in this case. I can tell you the structural problem with the code can be found on Lines 138, 139, 144, 145, 148, 149, 154, 155, 167, 170, 180, 182, 214, 215, 218, 219, 224, 225, 227, 229, 230, 245, 256, 312, 313, 356, 357, 675, 689, 772 etc. Basically anywhere you are accessing the global arrays you made between Lines 101 and 115 (they shouldn't be array's of pointers if I have any grasp of the material by the way, so delete that asterix in their definition) You are declaring one dimensional arrays, and addressing their elements as if they were much larger than they actually are.

This would be SO MUCH EASIER to do in C++ for the record. A 10 minute tutorial on dynamic arrays will clean up %75 of this mess.
Many thanks
I will try something
but without converting c++, can we just increase the dimension at the begnning?
Now I am in exam week I will look at it a week later
Topic archived. No new replies allowed.