C++ file gives segmentation fault error after any modifications

Question

I wrote a piece of C++ code to connect with RFID reader using LLRP API on CentOS 7 system (64bit) and it has been working perfectly. I took that very .cpp file and copied it to my Ubuntu 14.04 desktop (64bit as well) and after "make" -ing the file it runs successfully.

The issue arises when I try to edit the .cpp file. Even insertion or deletion of a single character/ blank space/ comments results in a "segmentation fault (core dump)".

The .cpp file can be successfully saved and compiled via "make" after edits, but while running the executable using ./ segmentation fault arrives.

I am using simple gedit and vim nothing else.I am guessing the issue is related to how both operating systems handle the text characters. Any clues?

More observations ---

As per suggestions, I have tried by deleting all the codes and kept just -

int main()
{
}

And the code ran successfully. So what can be the issue now?

* MORE DETAILS *

Following is the code snippet that is under suspicion -
/*
     * Check to make sure the message is of the right type.
     * The type label (pointer) in the message should be
     * the type descriptor for READER_EVENT_NOTIFICATION.
     */
    if(&CREADER_EVENT_NOTIFICATION::s_typeDescriptor != pMessage->m_pType)
    {
        goto fail;
    }
printf("Hello from check\n");
    /*
     * Now that we are sure it is a READER_EVENT_NOTIFICATION,
     * traverse to the ReaderEventNotificationData parameter.
     */
    pNtf = (CREADER_EVENT_NOTIFICATION *) pMessage;
printf("Hello from check 2\n");
printf("Hello from check 3");
    pNtfData = pNtf->getReaderEventNotificationData();
    if(NULL == pNtfData)
    {
        goto fail;
    }

The output is -

2902Z-001/RFID/example# ./example1 -v 169.254.209.30 124 5 INFO: Connecting to 169.254.209.30.... 6 7 INFO: Connected, checking status.... 8 9 Hello from check Hello from check 2 Segmentation fault (core dumped)

So clearly there is some problem between "Hello check 2" and "Hello check 3"

Is this a case of possible buffer overflow ?