Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Getpeername test #377

Open
wants to merge 18 commits into
base: develop
Choose a base branch
from
Open

Getpeername test #377

wants to merge 18 commits into from

Conversation

Yaxuan-w
Copy link
Member

Description

During the execution of the LAMP stack, it was discovered that the test suite lacked a test case for the getpeername function. This PR aims to add a test case for getpeername to make the test suite more comprehensive. To avoid issues related to "connection in use" that can occur with IPv4/IPv6 in a test suite, Unix Domain Sockets (UDS) are used for this test.

Type of change

Add test

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

How Has This Been Tested?

  • make test

Checklist:

  • My code follows the style guidelines of this project
  • I have commented my code, particularly in hard-to-understand areas
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • Any dependent changes have been added to a pull request and/or merged in other modules (native-client, lind-glibc, safeposix-rust)

Comment on lines +12 to +14
* use" issues when running them as part of a larger test suite. The purpose of this test
* is solely to verify that the getpeername function works as expected. Therefore, we
* opted to use UDS for this test.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a little confused. Could you test IPv4, IPv6, and UDS with this test? Why did you only pick one?

error("Failed to create server thread");
}

sleep(1);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this supposed to wait long enough for the server thread to complete? Would using locking or signals be better?

Copy link
Contributor

@yashaswi2000 yashaswi2000 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestions on replacing sleep for better stability.

int main() {
// Just in case this didnt get unlinked last time
unlink(SERVER_SOCKET_PATH);
unlink(CLIENT_SOCKET_PATH);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion to use semaphores instead of sleep, as it can lead to unstable tests

// Initialize the semaphore if (sem_init(&ready_flag, 0, 0) != 0) { error("Semaphore initialization failed"); }

}

sleep(1);

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

waiting for server to be ready
sem_wait(&ready_flag);

run_client();

pthread_join(server_thread, NULL);

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sem_destroy(&ready_flag);


printf("Server is listening on %s\n", SERVER_SOCKET_PATH);
fflush(stdout);

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sem_post(&ready_flag);


/*
* In this test case, we choose to use Unix Domain Sockets (UDS) instead of IPv4/IPv6.
* While running individual tests with IPv4/IPv6 works fine, we encounter "connection in
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would port randomization resolve this issue?

@rennergade
Copy link
Contributor

I agree with the other comments about syncronization. You may want to look at the pthread_barriers we use in some of the other tetsts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants