Linux Programming

28-Feb-20 5:43

I am looking for somebody who can help me to resolve this bluetooth issue.
( I'll ignore any replies NOT discussing / leading to resolution , including insults and RTFM comments )

Included is "bare bones " bluetooth code , I have not included any necessary #includes / library , but if it will help I can add them later if necessary.

I am still having an issue with "address already in use" , BUT my question for now is

why I cannot close and successfully reallocate "socket" ?

I understand that some functions DO NOT generate valid "errno" hence "invalid argument" is really somewhat bogus perror message, however SECOND call to socket should generate "Success" .

Again please concentrate on that for now.

Code output

RPI_BT_SERVER _X86 
date version Feb 28 2020
test time 10:17:50
 BRAEK @line 333
STATUS allocate socket : Success
STATUS close socket : Invalid argument
STATUS reallocate socket : Invalid argument this is the issue 
STATUS bind : Address already in use
STATUS listen : File descriptor in bad state
STATUS accept : File descriptor in bad state
accepted connection from 00:00:00:00:00:00

Code snippet:

C++

<pre>	struct sockaddr_rc loc_addr = { 0 }, rem_addr = { 0 };
	char buf[1024] = { 0 };
	int socket_fd, client_fd, bytes_read;
	socklen_t opt = sizeof(rem_addr);

	// allocate socket
	socket_fd= socket(AF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM);
	perror("STATUS allocate socket ");

	// close socket
	close(socket_fd);
	perror("STATUS close socket ");
	// re allocate socket
	socket_fd = socket(AF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM);
	perror("STATUS reallocate socket ");

	// bind socket to port 1 of the first available
	// local bluetooth adapter
	loc_addr.rc_family = AF_BLUETOOTH;

	struct hci_dev_info device_info;
	hci_devinfo(0, &device_info);

//  exit(1);

	loc_addr.rc_bdaddr = device_info.bdaddr; //   {"00:15:83:15:A2:CB"}; // "*BDADDR_ANY;
	loc_addr.rc_channel = (uint8_t) 1;
	bind(socket_fd, (struct sockaddr*) &loc_addr, sizeof(loc_addr));
	perror("STATUS bind ");
	// put socket into listening mode
	listen(socket_fd, 1);
	perror("STATUS listen ");
	// accept one connection
	client_fd = accept(socket_fd, (struct sockaddr*) &rem_addr, &opt);
	perror("STATUS accept ");
	ba2str(&rem_addr.rc_bdaddr, buf);
	fprintf(stderr, "accepted connection from %s\n", buf);
	memset(buf, 0, sizeof(buf));

	// read data from the client
	bytes_read = read(client_fd, buf, sizeof(buf));
	if (bytes_read > 0) {
		printf("received [%s]\n", buf);
	}

	// close connection
	close(client_fd);
	close(socket_fd);

Richard MacCutchan28-Feb-20 6:32

28-Feb-20 6:32

The invalid argument message on the close is saying the socket_fd is not a valid socket identifier. So none of the following calls are likely to succeed. Even though perror says success after the socket call, you should check the return value to see what it is.

Vaclav_28-Feb-20 7:12

28-Feb-20 7:12

Richard,
I have quit checking the actual file descriptor because perror gives a more information when it fails.
But after your post I added such check back.
I also replaced close with shutdown and still getting same results.

Since I still do not trust cerr /perror running on X86 I am going to switch to ARM where the cout / cerr "synchronization " is NOT an issue.

Interestingly , when I check the file descriptor on initial socket allocation , then the reallocated socket file descriptor is different.
I am not sure if that matter, but OS "should" always allocate lowest level file descriptor and that tells me that the original file descriptor is somehow still active.

One small note = I have to make sure perror actually reads the results of the socket call immediately after.

k505429-Feb-20 6:14

k5054

29-Feb-20 6:14

Vaclav_ wrote:
I have quit checking the actual file descriptor because perror gives a more information when it fails.

This could be a problem: perror() prints the associated error string with the current errno, but a successful library call does not reset errno to zero. If you're going to rely on perror(), and by extension errno, you need to make sure you set errrno to zero before any library call that might set errno. Otherwise, you could be getting invalid error information. Every library function I can think of will return a value that will indicate that it failed (e.g. -1 for open(), or NULL for fopen(), etc). You really should be testing the return value for failure before checking perror()

Vaclav_29-Feb-20 8:27

29-Feb-20 8:27

I have started doing both checks - return values and errno.
If I understand perror it does something special when errno is zero.
Perhaps I will try to keep track of errno.

There are two "weird" behaviour I am unable to grasp.

I am definitely getting different responses when running SAME code on X86 and ARM7.
I am working on that to make sure.

Even if errno is NOT changed between calls, getting "Invalid parameters" is puzzling when the parameters are SAME in both calls.

Here is a proof you are on the right track !

Code

C++

	// allocate socket
	socket_fd = socket(AF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM);
#ifdef TRACE
	cout << "Socket errno " << dec << errno << "  @line " << __LINE__ << endl;
	perror("STATUS allocate socket ");

this call sets the errno to 22 -  AFTER perror is executed with errno being set to 0 success!  
	
cout << "socket_fd  " << dec << socket_fd << endl;

this call 
	cout << "Socket errno " << dec << errno << "  @line " << __LINE__ << endl;
    //exit(-1);
#endif


	// reallocate socket
here the errno is still set to 22 ! 

	socket_fd = socket(AF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM);
#ifdef TRACE
	cout << "Socket errno " << dec << errno << "  @line " << __LINE__ << endl;
	perror("STATUS allocate socket ");
	cout << "socket_fd  " << dec << socket_fd << endl;
	cout << "Socket errno " << dec << errno << "  @line " << __LINE__ << endl;
    exit(-1);
#endif

Output

SERVER_X86_228 
RPI_ARM  
date version Feb 29 2020
test time 13:37:53
STATUS allocate socket : Success
 BREAK @line 47
Socket errno 0  @line 61
socket_fd  3
Socket errno 22  @line 64
Socket errno 22  @line 72
socket_fd  4
Socket errno 22  @line 75
STATUS allocate socket : Invalid argument

modified 29-Feb-20 14:47pm.

Richard MacCutchan29-Feb-20 21:19

29-Feb-20 21:19

Good point, I totally forgot about that.

Vaclav_1-Mar-20 4:02

1-Mar-20 4:02

perror(3) - Linux manual page[^]

Add a direct quote from man

When a system call fails, it usually returns -1 and sets the variable
       errno to a value describing what went wrong.  (These values can be
       found in <errno.h>.)  Many library functions do likewise.  The
       function perror() serves to translate this error code into human-
       readable form.  Note that errno is undefined after a successful
       system call or library function call: this call may well change this
       variable, even though it succeeds, for example because it internally
       used some other library function that failed.  Thus, if a failing
       call is not immediately followed by a call to perror(), the value of
       errno should be saved.

And I am not the only one using perror wrong. Take this gem
I have commented out here just to show the original code.
This "example" shows why some coders do not check the call result.

C++

	errcode = getaddrinfo("z_desktop", NULL, &hints, &res);
	//perror("STATE getaddrinfo");
	if (errcode != 0) {           // call returns "-errors " 
		//cout <<"errno " << dec << errno << endl;
		perror("STATE getaddrinfo");     
// perror prints "Success" !  getaddrinfo does not sets errno ! 
		//cout << " errcode (?) " << dec << errcode << endl;
		//cout << "hints.ai_addr " << dec <<  hints.ai_addr << endl;
		//cout <<"hints.ai_family  " << hints.ai_family << endl;
		return -1;
	}

Vaclav_28-Feb-20 8:32

Running console apps on windows 7

28-Feb-20 8:32

I have moved the code to run on RPi ARM and have NO ISSUES!
I shall go ahead and finish my experiment passing data using bluetooth on SAME hardware,
Perhaps when I get it fully working it will be easier to find why it fails on X86.
Thanks four your help.

Calin Negru23-Feb-20 20:07

23-Feb-20 20:07

how do you run a console program with arguments on windows 7? when you run it from the shell the window disapears instantly.

Victor Nijegorodov23-Feb-20 20:45

Victor Nijegorodov

23-Feb-20 20:45

You can beUsing Pause (The GNU C Library) before return from main().

Calin Negru23-Feb-20 21:22

23-Feb-20 21:22

thank you Victor

Richard MacCutchan23-Feb-20 20:59

23-Feb-20 20:59

Run it in a cmd window, just like in a Linux terminal.

Calin Negru23-Feb-20 21:21

23-Feb-20 21:21

notice taken, thank you Richard

getting started with ASM, what compilers do you use?

jsc4229-Feb-20 11:16

jsc42

29-Feb-20 11:16

use

cmd /k yourapp

- the /k prevents the window from closing once the app has finished running.

Calin Negru21-Feb-20 1:47

Re: getting started with ASM, what compilers do you use?

21-Feb-20 1:47

I`m learning assembler. I need advice for picking a compiler.

Richard MacCutchan21-Feb-20 1:52

Re: getting started with ASM, what compilers do you use?

21-Feb-20 1:52

The best starting point would be the manual for the assembler language that you are learning.

Calin Negru21-Feb-20 2:40

Re: getting started with ASM, what compilers do you use?

21-Feb-20 2:40

Thanks for feedback. I`m not using a manual as reference, I`m learning on my own.

modified 21-Feb-20 9:27am.

Richard MacCutchan21-Feb-20 3:54

Re: getting started with ASM, what compilers do you use?

21-Feb-20 3:54

Well you must be extremely talented.

Calin Negru21-Feb-20 6:39

Re: getting started with ASM, what compilers do you use?

21-Feb-20 6:39

thank`s for your compliment, I`m no different than any other person though.

Richard MacCutchan21-Feb-20 6:50

Re: getting started with ASM, what compilers do you use?

21-Feb-20 6:50

The point I was trying to make is that you need to make use of the learning materials that are available. And in the age of the internet there are millions of them.

Calin Negru21-Feb-20 7:04

Cross compilation mystery

21-Feb-20 7:04

I do what I can but I haven`t found exactly what I was looking for, though that`s only because I wasn`t looking for the right thing maybe. I know there is tons of material out there but I don`t trust them unless I`m specifically pointed to a resource by someone.
Richard thanks for your useful feedback.

modified 21-Feb-20 14:05pm.

fd97504-Feb-20 4:53

fd9750

4-Feb-20 4:53

Hi,

I had a nicely operating cross compilation tool setup ( see the article I wrote about it Toolset to Cross Compile/Remote Debug Raspberry from Windows Host[^] )

Today I tried to run a python script but it needed python 3.7. I did not have that in the Msys32 setup I was using. After some searching I tried to put the Msys32 configuration up to date but it completely failed and became totally inoperable. It was not even possible to start the Mingw32 shell in it any more.

I Also had an Msys64 setup available and tried to update that one and it worked perfectly. I installed python 3.8.1.1 and was able to run the python script from within the updated Mingw64 shell. The Msys64 setup also contains a Mingw32 shell which runs equally well.

So far so good but now I have a completely different problem: whenever I try to run the make command for my project ( either manually in the Mingw32 or Mingw64 shell or from Visual studio code ) I get a really odd error message:

$ make
mkdir -p build/./main/
The syntax of the command is incorrect.
make: *** [build/./main/hello_world_main.c.o] Error 1

It is the mkdir -p build/./main/ which appears to be the culprit but strangely enough that used to work perfectly and when I type the exact same command from within either the Mingw32 or Mingw64 shell it executes perfectly without the slightest trace of an error message.

For completeness I have included the Makefile content below but this has really thrown a spanner in the works. Does anyone have an idea as to what may be the cause of this?

TARGET_EXEC ?= Hello_world_c

BUILD_DIR ?= ./build
SRC_DIRS ?= ./main

SYSROOT = $(RPIDEV_LOC)/arm-linux-gnueabihf/sysroot
CROSS_COMPILE = $(RPIDEV_LOC)/bin/arm-linux-gnueabihf

CXX = $(CROSS_COMPILE)-g++ --sysroot $(SYSROOT)
CC = $(CROSS_COMPILE)-gcc --sysroot $(SYSROOT) -lpigpio
AS = $(CROSS_COMPILE)-as
AR = $(CROSS_COMPILE)-ar
NM = $(CROSS_COMPILE)-nm
LD = $(CROSS_COMPILE)-ld

SRCS := $(shell find $(SRC_DIRS) -name *.cpp -or -name *.c -or -name *.s)
OBJS := $(SRCS:%=$(BUILD_DIR)/%.o)
DEPS := $(OBJS:.o=.d)

INC_DIRS := $(shell find $(SRC_DIRS) -type d)
INC_FLAGS := $(addprefix -I,$(INC_DIRS))

CPPFLAGS ?= $(INC_FLAGS) -MMD -MP -g

$(BUILD_DIR)/$(TARGET_EXEC): $(OBJS)
	$(CC) $(OBJS) -o $@ $(LDFLAGS)

# assembly
$(BUILD_DIR)/%.s.o: %.s
	$(MKDIR_P) $(dir $@) 
	$(AS) $(ASFLAGS) -c $< -o $@

# c source
$(BUILD_DIR)/%.c.o: %.c
	$(MKDIR_P) $(dir $@)
	$(CC) $(CPPFLAGS) $(CFLAGS) -c $< -o $@

# c++ source
$(BUILD_DIR)/%.cpp.o: %.cpp
	$(MKDIR_P) $(dir $@)
	$(CXX) $(CPPFLAGS) $(CXXFLAGS) -c $< -o $@


.PHONY: clean

clean:
	$(RM) -r $(BUILD_DIR)

-include $(DEPS)

MKDIR_P ?= mkdir -p

Re: Cross compilation mystery

Richard MacCutchan4-Feb-20 6:14