I have a PEM Certificate generated using OpenSSL. The certificate is read using fopen call in C++. The X509 object is then copied into an unsigned char array using memcpy, and the ascii values of the array are displayed.
When I repeat the same process (reading the file, and displaying the ascii values), the results differ. Results differ across executions, as well as in the same execution.
This is how I am reading the certificate
FILE* f_cert = fopen(filename.str().c_str(), "r");
X509 *tempCert = NULL;
PEM_read_X509(f_cert, &tempCert, NULL, NULL);
This is how I display the certificate
memcpy (temp, tempCert, sizeof(Certi));
for (int a=0; a<sizeof(X509); a++){
cout << (int)temp[a] << " ";
}
Output-1:
16 216 64 1 0 0 0 0 128 223 64 1 0 0 0 0 160 223 64 1 0 0 0 0 0 0 0 0
1 0 0 0 208 232 64 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 255
255 255 255 255 255 255 255 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
Output-2:
16 216 212 0 0 0 0 0 128 223 212 0 0 0 0 0 160 223 212 0 0 0 0 0 0 0 0
0 1 0 0 0 208 232 212 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 255
255 255 255 255 255 255 255 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
But when I read the certificate's MD5, it stays the same. What could be an explanation for this?
I need to insert this certificate into a Bloom Filter.
Thanks in advance.
Related
I have to rewrite the source code to new version of OpenCV and I have problem with functions and class cvLoad, cvarrToMat and IplImage which doesn't exist in new version of OpenCV.
My old code is:
cv::Mat load(string path) {
IplImage * imgT = (IplImage*) cvLoad(path.c_str());
return cvarrToMat(imgT);
}
I get this error output while compiling:
error: 'IplImage' was not declared in this scope
The data which are loaded are depth maps from UTKinect 3D dataset.
Here is example of xml file:
<?xml version="1.0"?>
<opencv_storage>
<depthImg190 type_id="opencv-image">
<width>320</width>
<height>240</height>
<origin>top-left</origin>
<layout>interleaved</layout>
<dt>w</dt>
<data>
0 0 0 0 27120 27384 27120 27120 27384 27120 27120 27120 27120 27384
27384 27664 27664 27944 27944 27664 27664 27944 27944 27944 28224
27944 27944 28224 28224 28224 28224 28520 28816 29120 29120 29120
29120 29120 29120 29120 29432 29744 30072 30072 29744 29744 30072
30072 30072 30400 30400 30736 30736 31080 31080 31080 31440 31440
31440 31440 31800 31800 31800 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
...
I'm currently writing a function that will manipulate a 512x512 .BMP image and I'm struggling with reading in the pixel data. I'm including fstream in this to deal with reading the image data.
My function should work explicitly with 8-bit Grayscale .BMP images, so I really shouldn't need to worry about the file Headers. You can see in my code I just read the entire header into an array for later usage.
Here is my Constructor for my Image Class:
// Constructor
Image::Image(const char* inFileName){
// First we will initialize our Image Data Arrays:
ImageData = new int* [SIZE];
complexImageData = new complex<double>* [SIZE];
for(int i=0; i<SIZE; ++i){
ImageData[i] = new int [SIZE];
complexImageData[i] = new complex<double> [SIZE];
}
// Now we will initialize our I/O Files.
outFile = new ofstream;
inFile = new ifstream;
// And now we will fill our data arrays with the input file data.
inFile->open(inFileName,ios::in | ios::binary); // Reads file as binary
inFile->seekg(0,ios::beg); // sets filter position to beginning
inFile->read(header,HEADERSIZE); // Reads header
// Now to read in the image data:
for(int i=0; i<SIZE; ++i){
inFile->read(reinterpret_cast<char*>(ImageData[i]),SIZE);
for(int j=0; j<SIZE; ++j){
cout << ImageData[i][j] << ' ';
}
cout << endl;
}
inFile->close();
}
As you can see, it prints out the data as it is read in. The output of this constructor is strange to me. Here's the first 512 entries read into the ImageData array:
236854814 237117986 505286158 236854814 505290270 236854814 572662306 237112866 571346462 505290254 505288222 371072534 236328478 504763918 370546198 152442390 503911958 236330518 370546198 152439062 369690902 504763926 236852758 571347470 572662306 571351570 235802142 504237582 505290254 236330526 504241694 235802126 505290262 370546206 370548246 504765974 371070494 505288214 371072534 369694230 235806222 236854814 237117986 235802146 370548254 369690902 504763926 371072534 370546198 152442390 504760598 504763926 237117986 304226850 235802146 235802126 235807246 504241678 504761870 504237590 371072542 370548246 504763926 236854806 235802142 235802126 235802126 504242702 235802126 303178258 505286178 571351566 572662286 572658210 236065314 303178254 571609618 571351586 571613730 571351586 237112866 571351566 303702562 572658210 237112846 304222754 303700506 304226850 168434194 471079956 169088010 169088020 437914122 437918234 169085466 436865546 169482778 336204810 168430100 336857610 336862228 336204820 471077898 471866380 471079964 169090076 203168778 169088012 471077914 336862236 168430090 168434186 168434202 437918234 169482778 168430106 168430106 169482762 336206346 169085450 336206356 135796768 404228120 270014488 303698458 303174162 303174162 404752922 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
As you can see, approximately the second half of this data is all zeros. Another line is even stranger:
236852766 571346446 236850702 371072542 505291278 371070494 504763934 236330518 370548238 503911966 236852758 371072542 504763913 504237582 571350542 235802126 504242722 503911958 152966678 370542870 369694230 369690905 236330505 504237590 370548246 504763926 370546206 370546198 370546198 235806230 371073550 504763926 370548254 572658206 235807246 571346446 504237582 236854798 505553422 370548254 152442390 236852758 572662306 504765986 370546198 369694217 504763926 370548246 504241686 371072526 235804190 504765974 370542870 151587081 152635673 504763913 369690902 370546206 152443145 505290262 236852766 371072534 505284886 370546206 572397078 371072526 504237598 370548254 371070486 371073566 152439049 370542870 152442377 504763926 571350558 505286174 504765982 236854814 235806238 235802126 235807246 572399134 571351566 571613730 571611666 303698466 437916186 169478682 168430090 169089546 336862236 336860180 336204810 336857620 336202260 168432660 168430090 168430106 471075338 203431964 470551564 336202250 336860180 336860180 336862228 336204820 168430100 436865562 337384458 436868106 168430090 168430090 336204820 436865546 168430090 168432650 269487114 135796760 202905624 437918226 437918234 403705868 404232208 269490200 337252884 571613722 304222738 269228562 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 4 181497 53543152 0 53543152 0 57016416 0 57016416 0 57135104 0 925696 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
You can see that it also has the same zeros, but amongst those zeros are some unexpected non-zero entries. This is certainly not expected from the input image.
Any help would be greatly appreciated! I'm sorry if this is a duplicate but I tried so very hard to find an answer to my problem before posting this!
EDIT:
I noticed immediately that the numbers being printed (236854814, 237117986 etc) were not in the 8-bit range. I find this so confusing since I'm reading the data reinterpreted as a char, which is 8-bit on my system. Would it not be the case that the data being read into the integer array should be 8-bit? I even tried making my ImageData array of type __int8**, so that it could only store 8 bits per entry, but It still didn't work.
Your image is 8bpp grayscale but you read it into block int [SIZE] (supplying wrong buffer size in the process) potentially storing 4 pixel values in each int. If image is 8bpp you could've just used uint8_t buffer. You should also perform header validation (because right now your may read at wrong position) and check for actual amount of bytes read. Depending on image type / size you may also need to check padding for each line.
I have some issue where I wanted to send this information via web service. My program is using MFC 6.0. There are several other functions besides this UploadStripMapping and other functions works well. Somehow, I have some issue here where this data is not captured in the server's log. But, if I send data with wrong XML format, then the server will reply with format error.
Below is the statement that I wanted to send over:
<?xml version="1.0" encoding="utf-8"?> <soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope"> <soap12:Body> <UploadStripMapping xmlns="http://tempuri.org/"> <strXML><?xml version="1.0" encoding="utf-8"?>
<root>
<info>
<StripID>1234ABDD</StripID>
<LotID>B Version</LotID>
<Rows>18</Rows>
<Columns>48</Columns>
<Panels>4</Panels>
<MachineID>3RD019</MachineID>
<DateCreated>2016-07-04 13:27:43</DateCreated>
</info>
<Mapping>
<Col1>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col1>
<Col2>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col2>
<Col3>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col3>
<Col4>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col4>
<Col5>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col5>
<Col6>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col6>
<Col7>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col7>
<Col8>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col8>
<Col9>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col9>
<Col10>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col10>
<Col11>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col11>
<Col12>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col12>
<Col13>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col13>
<Col14>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col14>
<Col15>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col15>
<Col16>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col16>
<Col17>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col17>
<Col18>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col18>
<Col19>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col19>
<Col20>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col20>
<Col21>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col21>
<Col22>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col22>
<Col23>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col23>
<Col24>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col24>
<Col25>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col25>
<Col26>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col26>
<Col27>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col27>
<Col28>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col28>
<Col29>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col29>
<Col30>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col30>
<Col31>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col31>
<Col32>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col32>
<Col33>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col33>
<Col34>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col34>
<Col35>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col35>
<Col36>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col36>
<Col37>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col37>
<Col38>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col38>
<Col39>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col39>
<Col40>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col40>
<Col41>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col41>
<Col42>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col42>
<Col43>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col43>
<Col44>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col44>
<Col45>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col45>
<Col46>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col46>
<Col47>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col47>
<Col48>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</Col48>
</Mapping>
</root></strXML> </UploadStripMapping> </soap12:Body> </soap12:Envelope>
Here's how I write the send statement in my program, the data above I set as strXML:
HTTPMethod = _bstr_t( "POST" );
httpReq->open(HTTPMethod, HTTPUrl, _variant_t(VARIANT_FALSE), _variant_t(), _variant_t());
httpReq->setRequestHeader("Content-Type", "application/soap+xml");
szRequest.Format("<?xml version=\"1.0\" encoding=\"utf-8\"?> \ <soap12:Envelope xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\" xmlns:soap12=\"http://www.w3.org/2003/05/soap-envelope\"> \
<soap12:Body>\
<UploadStripMapping xmlns=\"http://tempuri.org/\"> \
<strXML>\ %s \ </strXML>\
</UploadStripMapping>\
</soap12:Body>\
</soap12:Envelope>", strXML);
vRequest.vt = VT_BSTR;
vRequest.bstrVal = szRequest.AllocSysString();
httpReq->send(vRequest);
bsResponse = httpReq->responseText;
Can anyone give some advice or point out my mistake in this code? Thanks for your help in advance.
I want to determine if a CU has been intra or inter encoded with the HEVC reference software HM 16.4 encoder.
In TEncSlice.cpp, after a CTU has been compressed (m_pcCuEncoder->compressCtu( pCtu );), I should be able to tell if a CU is intra or inter encoded.
Therefore, I check the m_pePredMode array of TComDataCU* pCtu:
Char* predMode = pCtu->getPredictionMode();
for (int i = 0; i < pCtu->getTotalNumPart(); i++)
{
std::cout << (int)predMode[i] << " ";
}
std::cout << std::endl;
PredMode is defined in TypeDef.h as:
enum PredMode
{
MODE_INTER = 0, ///< inter-prediction mode
MODE_INTRA = 1, ///< intra-prediction mode
NUMBER_OF_PREDICTION_MODES = 2,
};
The output of my code first gives me the expected result. For the first intra frame, I first only get ones (MODE_INTRA). But for certain CTUs, I also get "twos", which doesn't really make sense to me, as 2 is not supposed to describe a prediction mode.
Similarly, in the inter frames (P frames), I mostly get zeros (MODE_INTER), a few ones (MODE_INTRA), which is ok. But then I also get some "twos". A part of an example output looks like this (each row corresponds to a 64x64 CTU):
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 0 0 0 0 0 0 0 0 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 1 1 1 1 0 0 0 0 0 0 0 0 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
Does anyone know what these mean? I checked if this would correspond to skip mode, but there was no correlation between the skip flag and the 2s.
Well, I got the answer to this question:
If a CU has predMode 2, this means that the CU is not coded. This happens in this case because the CUs are outside the boundaries of the picture.
The sequence that was coded had a resolution of 416x240 and the CTU size was 64x64. So there are 6.5 CTUs in a row.
This explain why every 7 CTUs, I get 2s as predMode.
Consider this simple program:
#include <exception>
#include <iostream>
int main(void)
{
const std::size_t size = 1<<31;
int *a = NULL;
try
{
a = new int[size];
}
catch (std::exception &e)
{
std::cerr << "caught some bad guy" << std::endl;
return 1;
}
if (a == NULL)
{
std::cerr << "it's null, can't touch this" << std::endl;
return 1;
}
std::cerr << "looks like 'a' is allocated alright!" << std::endl;
for (size_t i = 0; i < size; i ++)
std::cout << a[i] << " ";
return 0;
}
Commentary
I try to allocate some ridiculous amount of memory: (1<<31) * sizeof(int) == 8GB
I add safety checks
Catching std::exception, which should catch std::bad_alloc among other exceptions...
Check if it's not null (even though for this check to actually make sense, I'd need a = new (std::nothrow) int[size] - but regardless of how I allocate memory, it doesn't work)
Environment
RAM installed: 2GB
Operating system: Debian
Architecture: 32-bit
Problem
The problem is that the program, instead of early exit, does something like this:
rr-#burza:~$ g++ test.cpp -o test && ./test
looks like 'a' is allocated alright!
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
(...many other zeros here...)
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0Segmentation fault
The number of zeros printed is exactly 33790, which tells me exactly... nothing.
How can I make my program segfault-proof?
This seems to be a bug in your environment, which causes integer overflow in implementation of new[]. In effect, you are allocating 0 bytes. It might be this bug. C++03 standard is not clear about what should happen, in C++11 std::bad_array_new_length should be thrown.
If you need to support this system you can check if there is chance for overflow before allocating, for example:
size_t size_t_max = -1;
if (size > size_t_max / sizeof(int))
throw ...;
This bug might still affect you however if libraries you use don't have such checks (for example implementation of std::vector).