LinuxQuestions.org - writing "\r" to /dev/ttyS* causes segmentation fault

- Programming (https://www.linuxquestions.org/questions/programming-9/)

- - writing "\r" to /dev/ttyS* causes segmentation fault (https://www.linuxquestions.org/questions/programming-9/writing-%5Cr-to-dev-ttys%2A-causes-segmentation-fault-867477/)

This is my open_port function, in case it sheds any light...

Code:

int comm_handler::open_port(const char* modemdevice) {



        fd = open(modemdevice, O_RDWR | O_NOCTTY );

        if (fd == -1) {

                syslog(LOG_ERR,"Could not open comm port");

                exit(-1);

        }

        else {

                fcntl(fd,F_SETFL,O_ASYNC);

                tcgetattr(fd,&options);

                options.c_cflag |= (CLOCAL | CREAD);

                options.c_cflag &= ~PARENB;

                options.c_cflag &= ~CSTOPB;

                options.c_cflag &= ~CSIZE;

                options.c_cflag |= CS8;

                options.c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG);

                options.c_oflag &= ~OPOST;

                options.c_iflag &= ~(ICRNL|IXON|IXOFF);

                options.c_cc[VMIN]=0;

                options.c_cc[VTIME]=0;

                cfsetispeed(&options,BAUDRATE);

                cfsetospeed(&options,BAUDRATE);

                tcsetattr(fd,TCSANOW,&options);

        }

        syslog(LOG_ERR,"comm_handler::open_port reports fd = %d",fd);

        return fd;

}

Quote:

Originally Posted by wje_lq (Post 4284634)

Oh! Well, then.

It turns out I have one of those. A US Robotics Courier. Once a month I use it to dial out to the National Bureau of Standards folks to find out what time it is. I wrote a C program which does this. As long as I was doing it, I wrote (inside the source file) a 950-line comment on how to program your modem in C. Can't hurt to give it a look-see, right?

For at least the next two weeks, you can get it here.

Cool. Grabbed a copy and am going through it now. Thanks alot!

Now I'm gettting these in my syslogs...

Code:

segfault at 2e ip 0000002e sp bfeceb80 error 4 in alarmd[8048000+11000]

"alarmd" is the name of the executable. I have no idea what anything else means.

Another thought. After you did the upgrade, did you reboot? Is it possible that some of the machinery that makes the serial port work is now out of sync with the kernel/driver/libraries, and needs a reboot to get things right again? That wouldn't explain why mionicom seems to be immune to the problem, but easy enough to try, even if it is a bit Windows-ish.

Pretty sure the 'ip' and 'sp' in your error message are the Instruction Pointer and Stack Pointer registers, respectively. You'd find those useful, I think, if you had a core dump to analyze.

--- rod.

Quote:

Originally Posted by theNbomr (Post 4284842)

I did reboot. It's part of the process of the installation and I did it again when I noticed the program had stopped working.

Quote:

Pretty sure the 'ip' and 'sp' in your error message are the Instruction Pointer and Stack Pointer registers, respectively. You'd find those useful, I think, if you had a core dump to analyze.

And if I had any clue what to do with them. Alas, my debugging skills are mediocre at best. If you have a pointer to where I might be able to learn some more, I'd appreciate it. I have googled but it looks a little like dark magic to me and I don't have a clue where to start.

Have you tried to build and run any other program? I wonder if your GCC installation is fried.

I haven't, but I have a sneaking suspicion it may be a hosed library. At the moment I'm downgrading the machine to the last known good installation where the program worked. I have to get it running again. I'm wondering if it didn't have something to do with the upgrade procedure since both boxes were upgraded the same way. I may grab an old machine and do a fresh install of the new OS and see if my program will run on it.

Well, my only take on the IP & SP matter is that the IP is a very low value (0x2E). I don't know this for sure, but my hunch is that it is in code that is part of the C startup code, and executing before it has reached your C main() function. By extension of this logic, it would indeed point to a problem with the C startup code that may come from a shareable object library.

Did this problem start without having re-built your application, or did it work fine until after you re-built it? If the former, then it would seem also to point to a shared object library problem. Is it possible that there is a 64/32-bit aspect to the problem (ie ld.so finding the wrong version first, now, where it previously found the correct one first). If you run ldd against your compiled application, does it list any libraries that have changed since your upgrade? Any libs that exist in more than one location?

Sorry to be throwing ideas at you in a scattershot fashion. I'm just trying to open up some ideas for exploration.

--- rod.

Quote:

Originally Posted by theNbomr (Post 4285593)

I rebuilt the application because it wouldn't stay running. I have run into this in the past with an operating system upgrade (it started with Slackware 7, I believe) and usually a recompile fixes it. I will run ldd and see what it says and also check for duplicate libraries.

Quote:

Sorry to be throwing ideas at you in a scattershot fashion. I'm just trying to open up some ideas for exploration.

Don't apologize. I appreciate any help you can give me. At this point I'm out of ideas, so even scattershot ones are more than welcome.

Downgrading the server worked. The application runs fine. Now to find out why.