Attached is a very simple program which connects a socket to a remote host and reads one char. The connection works and input data is pending, but the program core dumps during the attempt to read from the socket. I would appreciate if someone could let me know if (and how) I am misusing the TCPStream class. Details:
> make
g++ -I. -I/usr/local/include/cc++ -O -D_GNU_SOURCE -D_REENTRANT -D_THREAD_SAFE -c -o test.o test.cc
In file included from /usr/include/fcntl.h:18,
from /usr/local/include/cc++/config.h:286,
from /usr/local/include/cc++/socket.h:44,
from test.cc:2:
/usr/include/sys/feature_tests.h:143: warning: `_POSIX_PTHREAD_SEMANTICS' redefined
/usr/local/include/cc++/config.h:251: warning: this is the location of the previous definition
g++ -L/usr/local/lib test.o -lccxx -lsocket -lposix4 -lpthread -lsocket -o test
>
>
> ./test
1
0
Segmentation fault (core dumped)
>
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2001-07-06
Actually the work around in bug report 435074 using TCPStream::underflow() makes the program run to completion. The resulting program is attached. Could anyone explain why this is needed?
---------
#include <iostream.h>
#include <socket.h>
class MyStream : public TCPStream
{
public:
MyStream (InetHostAddress& host, int port, int size) : TCPStream(host,port,size)
{ }
using TCPStream::underflow;
};
int main(int argc, const char **argv)
{
char* host_name = "snms2";
int port = 2234;
char buffer[1000];
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2001-07-11
One more followup -- After working with the code a bit more, it appears that the work around in bug report 435074 using TCPStream::underflow() is not the answer. You still can make the application program core dump, or not, by making assorted minor and unrelated changes to the code. It sure seems like something used by the TCPStream class is writing in memory that it does not own, and clobbering other parts of the application.
To me, it looks like TCPStream is currently unusable until this bug is fixed!!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've same trouble under FreeBSD 4.3 + CommonC++ 1.5.
Are developers have tested its demo/tcp.cpp? It compiles and core dumps while reading from stream via >> operator.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Attached is a very simple program which connects a socket to a remote host and reads one char. The connection works and input data is pending, but the program core dumps during the attempt to read from the socket. I would appreciate if someone could let me know if (and how) I am misusing the TCPStream class. Details:
Solaris 8
commonc++-1.5.0
----------------
#include <iostream.h>
#include <socket.h>
int main(int argc, const char **argv)
{
char* host_name = "snms2";
int port = 2234;
char buffer[1000];
InetHostAddress host_addr(host_name);
TCPStream host(host_addr,port,70000);
// Wait a bit to make sure the server has sent its response.
sleep(2);
cout << host.isPending(SOCKET_PENDING_INPUT, 2000) << endl;
cout << host.isPending(SOCKET_PENDING_ERROR, 2000) << endl;
// Now let's try to read a char from the socket.
// This next line fails.
host >> buffer[0];
cout << "Read done." << endl;
}
-------------
> make
g++ -I. -I/usr/local/include/cc++ -O -D_GNU_SOURCE -D_REENTRANT -D_THREAD_SAFE -c -o test.o test.cc
In file included from /usr/include/fcntl.h:18,
from /usr/local/include/cc++/config.h:286,
from /usr/local/include/cc++/socket.h:44,
from test.cc:2:
/usr/include/sys/feature_tests.h:143: warning: `_POSIX_PTHREAD_SEMANTICS' redefined
/usr/local/include/cc++/config.h:251: warning: this is the location of the previous definition
g++ -L/usr/local/lib test.o -lccxx -lsocket -lposix4 -lpthread -lsocket -o test
>
>
> ./test
1
0
Segmentation fault (core dumped)
>
Actually the work around in bug report 435074 using TCPStream::underflow() makes the program run to completion. The resulting program is attached. Could anyone explain why this is needed?
---------
#include <iostream.h>
#include <socket.h>
class MyStream : public TCPStream
{
public:
MyStream (InetHostAddress& host, int port, int size) : TCPStream(host,port,size)
{ }
using TCPStream::underflow;
};
int main(int argc, const char **argv)
{
char* host_name = "snms2";
int port = 2234;
char buffer[1000];
InetHostAddress host_addr(host_name);
MyStream host(host_addr,port,70000);
// Wait a bit to make sure the server has sent its response.
sleep(2);
cout << host.isPending(SOCKET_PENDING_INPUT, 2000) << endl;
cout << host.isPending(SOCKET_PENDING_ERROR, 2000) << endl;
// Now let's try to read a char from the socket.
// This next line fails.
host.underflow();
host >> buffer[0];
cout << "Read done." << endl;
}
One more followup -- After working with the code a bit more, it appears that the work around in bug report 435074 using TCPStream::underflow() is not the answer. You still can make the application program core dump, or not, by making assorted minor and unrelated changes to the code. It sure seems like something used by the TCPStream class is writing in memory that it does not own, and clobbering other parts of the application.
To me, it looks like TCPStream is currently unusable until this bug is fixed!!
I've same trouble under FreeBSD 4.3 + CommonC++ 1.5.
Are developers have tested its demo/tcp.cpp? It compiles and core dumps while reading from stream via >> operator.