I have a run.sh script:
expr 1 + 1
what I actually want to instrument is expr.
Here is My Pin tool's code(I only instrument indirect calls to avoid the output became to large):
/*
* Copyright (C) 2004-2021 Intel Corporation.
* SPDX-License-Identifier: MIT
*/
#include <iostream>
#include <fstream>
#include <set>
#include "pin.H"
#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
#include <stdlib.h>
using std::cerr;
using std::endl;
using std::ios;
using std::ofstream;
using std::string;
using namespace std;
pid_t trg_pid = 0;
VOID print_ins(ADDRINT addr) {
cout<<PIN_GetPid()<<'\t'<<trg_pid<<'\t'<<hex<<addr<<oct<<endl;
}
// Pin calls this function every time a new instruction is encountered
VOID Instruction(INS ins, VOID* v)
{
if(INS_IsCall(ins) && INS_IsIndirectControlFlow(ins))
{
INS_InsertCall(ins, IPOINT_BEFORE, (AFUNPTR)print_ins, IARG_INST_PTR,IARG_END);
}
}
BOOL FollowChild(CHILD_PROCESS cProcess, VOID* userData)
{
int argcc;
char ** argvv;
CHILD_PROCESS_GetCommandLine(cProcess,&argcc,(const char* const**)&argvv);
if(string(argvv[0]).find("expr") != string::npos)
{
trg_pid = PIN_GetPid();
cout<<"trgpid : "<<trg_pid<<endl;
}
return TRUE;
}
// This function is called when the application exits
VOID Fini(INT32 code, VOID* v)
{
// Write to a file since cout and cerr maybe closed by the application
cout<<"finish"<<endl;
}
/* ===================================================================== */
/* Print Help Message */
/* ===================================================================== */
INT32 Usage()
{
cerr << "This tool counts the number of dynamic instructions executed" << endl;
cerr << endl << KNOB_BASE::StringKnobSummary() << endl;
return -1;
}
/* ===================================================================== */
/* Main */
/* ===================================================================== */
/* argc, argv are the entire command line: pin -t <toolname> -- ... */
/* ===================================================================== */
int main(int argc, char* argv[])
{
// Initialize pin
if (PIN_Init(argc, argv)) return Usage();
PIN_AddFollowChildProcessFunction(FollowChild, 0);
// Register Instruction to be called to instrument instructions
INS_AddInstrumentFunction(Instruction, 0);
// Register Fini to be called when the application exits
PIN_AddFiniFunction(Fini, 0);
// Start the program, never returns
PIN_StartProgram();
return 0;
}
and I run Pin using the following command:
/home/lzy/Desktop/pin-3.25-98650-g8f6168173-gcc-linux/pin -follow_execv -t /home/lzy/Desktop/pin-3.25-98650-g8f6168173-gcc-linux/source/tools/MyPinTool/obj-intel64/MyPinTool.so -- ./run.sh
and the output:
256709 0 7f42258b185a
765305 0 7f422589f9fd
765305 0 7f422589f908
765305 0 7f422589f9fd
765305 0 7f422589f908
765305 0 7f42258b4dc7
765305 0 7f42258b4e81
765305 0 7f42258b4f3d
765305 0 7f42258b4ff9
765305 0 7f42258b50b4
765305 0 7f42258af5cf
765305 0 7f42258af99b
765305 0 7f422589a752
765305 0 7f422589a799
765305 0 7f42258af368
765305 0 7f42258b91fa
765305 0 7f4225898a53
765305 0 7f422589f9fd
765305 0 7f422589fd1b
765305 0 7f422589f908
765305 0 7f42258af368
765305 0 7f4225895a54
765305 0 7f4225895f4c
765305 0 7f42258af470
765305 0 7f42258a82d7
765305 0 7f42258a82d7
765305 0 7f42258a82d7
765305 0 7f42258a82d7
765305 0 7f42258b2d68
765305 0 7f42258a642b
765305 0 7f42258a64a0
765305 0 7f42258a36e9
765305 0 7f42258a3091
765305 0 7f42258a3091
765305 0 7f42258a3091
765305 0 7f42258a3091
765305 0 7f42258a3091
765305 0 7f42258a3091
765305 0 7f42258a3091
765305 0 7f42258a3091
765305 0 7f42258a3091
765305 0 7f42258a3091
765305 0 7f42258a3091
765305 0 7f42258a3091
765305 0 7f42258a3091
765305 0 7f42258a3091
765305 0 7f42258a3091
765305 0 7f42258a3091
765305 0 7f42258a3091
765305 0 7f42258a3091
765305 0 7f42258a3091
765305 0 7f42258a3091
765305 0 7f42258a3091
765305 0 7f42258a3091
765305 0 7f42258a3091
765305 0 7f42258a3091
765305 0 7f42258a3091
765305 0 7f42258a3091
765305 0 7f42258a3091
765305 0 7f42258a3091
765305 0 7f42258a3091
765305 0 7f42258a3091
765305 0 7f42258a3091
765305 0 7f42258a3091
765305 0 7f42258a3091
765305 0 7f42258a3091
765305 0 7f42258a3091
765305 0 7f42258a3091
765305 0 7f42258a3091
765305 0 7f42258a3091
765305 0 7f42258a3091
765305 0 7f42258a3091
765305 0 7f42258a3a8d
765305 0 7f42258a3a8d
765305 0 7f42258a3a8d
765305 0 7f42258a3a8d
765305 0 7f42258a3a8d
765305 0 7f42258a3a8d
765305 0 7f42258a3a8d
765305 0 7f42258a3a8d
765305 0 7f42258a3a8d
765305 0 7f42258a3a8d
765305 0 7f42258a3a8d
765305 0 7f42258a3a8d
765305 0 7f42258a3a8d
765305 0 7f42258a3a8d
765305 0 7f42258a3a8d
765305 0 7f42258a3a8d
765305 0 7f42258a6524
765305 0 7f42258a6675
765305 0 7f422589786c
765305 0 7f42258a36e9
765305 0 7f422589847c
765305 0 7f422589847c
765305 0 55857ba33f0f
765305 0 7f4211abde66
765305 0 7f4211abdeb9
765305 0 7f4211abdd8e
765305 0 55857ba45061
765305 0 55857ba45061
765305 0 7f4211b091c8
765305 0 7f4211b09d25
765305 0 7f4211b0a047
765305 0 55857ba3bbfe
trgpid : 765310
256712 0 7fb6e21c885a
765310 0 7fb6e21b69fd
765310 0 7fb6e21b6908
765310 0 7fb6e21b69fd
765310 0 7fb6e21b6908
765310 0 7fb6e21cbdc7
765310 0 7fb6e21cbe81
765310 0 7fb6e21cbf3d
765310 0 7fb6e21cbff9
765310 0 7fb6e21cc0b4
765310 0 7fb6e21c65cf
765310 0 7fb6e21c699b
765310 0 7fb6e21b1752
765310 0 7fb6e21b1799
765310 0 7fb6e21c6368
765310 0 7fb6e21d01fa
765310 0 7fb6e21afa53
765310 0 7fb6e21b69fd
765310 0 7fb6e21b6d1b
765310 0 7fb6e21b6908
765310 0 7fb6e21c6368
765310 0 7fb6e21d01fa
765310 0 7fb6e21afa53
765310 0 7fb6e21b69fd
765310 0 7fb6e21b6d1b
765310 0 7fb6e21b6908
765310 0 7fb6e21c6368
765310 0 7fb6e21aca54
765310 0 7fb6e21c6368
765310 0 7fb6e21aca54
765310 0 7fb6e21acf4c
765310 0 7fb6e21c6470
765310 0 7fb6e21bf2d7
765310 0 7fb6e21bf2d7
765310 0 7fb6e21bf2d7
765310 0 7fb6e21bf2d7
765310 0 7fb6e21bf2d7
765310 0 7fb6e21c9d68
765310 0 7fb6e21bd42b
765310 0 7fb6e21bd4a0
765310 0 7fb6e21ba6e9
765310 0 7fb6e21ba091
765310 0 7fb6e21ba091
765310 0 7fb6e21ba091
765310 0 7fb6e21ba091
765310 0 7fb6e21ba091
765310 0 7fb6e21ba091
765310 0 7fb6e21ba091
765310 0 7fb6e21ba091
765310 0 7fb6e21ba091
765310 0 7fb6e21ba091
765310 0 7fb6e21ba091
765310 0 7fb6e21ba091
765310 0 7fb6e21ba091
765310 0 7fb6e21ba091
765310 0 7fb6e21ba091
765310 0 7fb6e21ba091
765310 0 7fb6e21ba091
765310 0 7fb6e21ba091
765310 0 7fb6e21ba091
765310 0 7fb6e21ba091
765310 0 7fb6e21ba091
765310 0 7fb6e21ba091
765310 0 7fb6e21ba091
765310 0 7fb6e21ba091
765310 0 7fb6e21ba091
765310 0 7fb6e21ba091
765310 0 7fb6e21ba091
765310 0 7fb6e21ba091
765310 0 7fb6e21ba091
765310 0 7fb6e21ba091
765310 0 7fb6e21ba091
765310 0 7fb6e21ba091
765310 0 7fb6e21ba091
765310 0 7fb6e21ba091
765310 0 7fb6e21ba091
765310 0 7fb6e21ba091
765310 0 7fb6e21ba091
765310 0 7fb6e21ba091
765310 0 7fb6e21ba091
765310 0 7fb6e21ba091
765310 0 7fb6e21baa8d
765310 0 7fb6e21baa8d
765310 0 7fb6e21baa8d
765310 0 7fb6e21baa8d
765310 0 7fb6e21baa8d
765310 0 7fb6e21baa8d
765310 0 7fb6e21baa8d
765310 0 7fb6e21baa8d
765310 0 7fb6e21baa8d
765310 0 7fb6e21baa8d
765310 0 7fb6e21baa8d
765310 0 7fb6e21baa8d
765310 0 7fb6e21baa8d
765310 0 7fb6e21bd524
765310 0 7fb6e21bd675
765310 0 7fb6e21ae86c
765310 0 7fb6e21ba6e9
765310 0 7fb6e21af47c
765310 0 7fb6e21af47c
765310 0 7fb6e21af438
765310 0 7fb6e21af47c
765310 0 55690b901b4f
765310 0 7fb6ce26ce66
765310 0 7fb6ce26cd8e
765310 0 7fb6ce279c06
765310 0 7fb6e21bc0d0
765310 0 7fb6ce5c4192
765310 0 7fb6ce5c4192
765310 0 55690b90c5e2
765310 0 7fb6e21bc0d0
765310 0 7fb6ce2c3053
765310 0 7fb6ce2ce752
765310 0 7fb6ce2d0d5d
765310 0 7fb6ce2c1bed
765310 0 7fb6ce288493
765310 0 7fb6ce2c2227
765310 0 7fb6ce2cfa5d
2
765310 0 7fb6ce2cef78
finish
I want to filter the instruction executed in expr by using a global variable trg_pid, but trg_pid is still 0 after i changed its value in FollowChild. Anyone has any idea? Thanks in advance!
It appears expr 1 + 1 uses the execve system call to execute the child program. An important feature of execve is that the process does not change, so the process ID will not change either.
The reason trg_pid remains 0 is because when the pintool calls FollowChild, only the parent program's version of trg_pid is set to the PID. This is because:
Pin_AddFollowChildProcessFunction executes before the child program executes.
Pin instruments both programs independently, i.e., they both have their own copy of trg_pid.
After FollowChild executes, the output you see is the result of instrumenting the child program, which has the same process ID as the parent but still has the default trg_pid value of 0.
The example you posted is kind of misleading because you do not see the process ID update until the call to FollowChild happens. In reality, something else changed the process ID. Based on an strace, it looks like there is a call to vfork shortly before execve. The child spawned by vfork executes execve. Your pintool does not currently track vfork. To do that, you can try to instrument fork functions via PIN_AddForkFunction().
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 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.
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).