Skip to main content

​
Build Errors

Minitalk requires the custom libft library with ft_printf implementation.Solution:
  • Ensure libft/ft_printf.h exists and is accessible
  • The header must include declarations for:
    • int ft_printf(char const *str, ...)
    • Standard library includes: <stdio.h>, <unistd.h>, <stdarg.h>, <stdlib.h>
  • Build the libft library before compiling minitalk
The project requires proper signal handling support.Solution:
  • Ensure your compiler supports POSIX signal handling
  • Required headers must be available: <signal.h>, <unistd.h>
  • Compile on a UNIX-like system (Linux, macOS, BSD)
Errors about undefined references to ft_printf or related functions.Solution:
  • Link against the compiled libft library
  • Ensure all ft_printf helper functions are included:
    • ft_write_str
    • ft_write_num
    • ft_write_pointer
    • ft_write_char

​
Runtime Errors

Error Message:
Wrong PID
Cause: The client validates that the PID argument contains only numeric characters. This error occurs when:
  • The PID contains non-digit characters
  • The PID includes letters, symbols, or spaces
Code Location: client.c:77-84
while (argv[1][j] != '\0')
{
    if (argv[1][j] < '0' || argv[1][j] > '9')
    {
        ft_printf("Wrong PID\n");
        return (1);
    }
    j++;
}
Solution:
  • Ensure the PID is numeric only (e.g., 12345, not 12a45)
  • Get the correct server PID from the server’s startup output
  • Do not include spaces or special characters in the PID
Error Message:
Client failed sending signal
Cause: The kill() system call returned -1, indicating signal delivery failed. This happens when:
  • The target PID does not exist
  • The target process has terminated
  • Permission denied (trying to signal a process owned by another user)
  • Invalid PID value (0, negative, or exceeds system maximum)
Code Location: client.c:55-61
if ((str[i] >> bits) & 1)
{
    if (kill(pid, SIGUSR2) == -1)
        return (1);
}
else
{
    if (kill(pid, SIGUSR1) == -1)
        return (1);
}
Solution:
  • Verify the server is running: ps -p <PID>
  • Check that the PID matches the server’s displayed PID exactly
  • Ensure you have permission to send signals to the process
  • Run both client and server as the same user
  • If the server crashed, restart it and use the new PID
Error Message:
Usage : ./client <PID> <string to send>
Cause: The client requires exactly 3 arguments (program name, PID, message). This error occurs when:
  • Wrong number of arguments provided
  • Empty string provided as the message (NULL check fails)
Code Location: client.c:75-76
if (argc != 3 || !argv[2])
    return (ft_printf("Usage : ./client <PID> <string to send>\n"), 1);
Solution:
# Correct usage
./client 12345 "Hello, World!"

# Wrong - missing message
./client 12345

# Wrong - missing PID and message
./client

​
Signal Delivery Issues

Symptoms:
  • Server displays garbled characters
  • Only partial message appears
  • Random characters printed
Possible Causes:
  1. Signal handler not properly registered
    • Server must call signal(SIGUSR1, handle_sigusr) and signal(SIGUSR2, handle_sigusr) before entering main loop
    • Verify in server.c:38-39
  2. Server not running in pause loop
    • Server must call pause() to wait for signals
    • Verify infinite loop at server.c:40-43
  3. Race condition between signals
    • Signals sent too quickly may not all be processed
    • See timing issues below
Solution:
  • Ensure server displays startup messages including PID
  • Verify signal handlers are registered before client sends signals
  • Check that server process remains running during transmission
Symptoms:
  • Client fails immediately with “Client failed sending signal”
  • kill() returns -1 with EPERM error
Cause: UNIX systems restrict signal sending between processes owned by different users.Solution:
  • Run both server and client as the same user
  • Check process ownership: ps -o user,pid,comm -p <PID>
  • Do not run server as root unless necessary
  • If using sudo, run both processes with sudo (not recommended)
Symptoms:
  • Client completes without errors
  • Server displays nothing or incomplete message
  • No output after server startup
Possible Causes:
  1. Server blocked or hung
  2. Signal handlers not properly set up
  3. Server terminated unexpectedly
Debugging Steps:
# Check if server is still running
ps -p <PID>

# Check server status
ps aux | grep server

# Send test signal manually
kill -SIGUSR1 <PID>
Solution:
  • Restart the server
  • Check server output for error messages
  • Ensure server’s pause() loop is executing
  • Verify signal handlers are correctly registered

​
Timing Problems

The usleep delay between signals is critical for reliable communication. Timing issues are the most common cause of message corruption.
Current Value: usleep(700) - 700 microseconds between signalsLocation: client.c:63Symptoms if too low:
  • Signals arrive before previous signal is fully processed
  • Operating system may merge or drop signals
  • Characters appear corrupted or missing
  • Message only partially received
Why this matters:
  • UNIX signals are not queued by default for SIGUSR1/SIGUSR2
  • If multiple identical signals arrive while one is being handled, extras may be lost
  • Signal handler execution takes time
  • System scheduling introduces delays
Solution:
  • If experiencing corruption, increase to usleep(1000) or higher
  • Test with longer delays first, then optimize downward
  • Balance between speed and reliability
Symptoms:
  • Messages work sometimes but fail under load
  • Corruption occurs when system is busy
  • Reliable on quiet system, unreliable otherwise
Cause: High system load can delay signal processing, causing even the 700μs delay to be insufficient.Solution:
  • Increase usleep() delay to 1000-2000 microseconds
  • Reduce system load (close unnecessary processes)
  • Consider implementing acknowledgment mechanism (bonus feature)
To test different timing values, modify the usleep call in client.c:63:
// Conservative (slower but more reliable)
usleep(2000);  // 2 milliseconds

// Current default
usleep(700);   // 700 microseconds

// Aggressive (faster but may fail)
usleep(100);   // 100 microseconds - NOT RECOMMENDED
Testing procedure:
  1. Start server: ./server
  2. Send test messages of varying lengths
  3. Verify complete, uncorrupted output
  4. Test with different system loads
  5. Find minimum reliable delay for your system

​
Server-Specific Issues

Expected Output:
SUCCESS!, Server is ready :D! The PID: 12345
Waiting fot the string...
If nothing appears:
  • Check that server executable has correct permissions
  • Ensure ft_printf is linked correctly
  • Verify server compiles without errors
  • Run with output redirection: ./server > output.txt 2>&1
Solution:
  • Rebuild the project completely
  • Test ft_printf independently
  • Check that stdout is not redirected or buffered
Issue: The handle_sigusr function uses static variables c and i to maintain state between signal handler calls.Location: server.c:18-19
static size_t	c = 0;
static size_t	i = 0;
Behavior:
  • Variables persist across all signal handler invocations
  • Not reset between different messages
  • Reset only after completing each character (every 8 bits)
Impact:
  • First message works correctly
  • Subsequent messages continue from previous state
  • If client connection interrupted mid-character, server state may be misaligned
Solution:
  • Restart server between messages if corruption occurs
  • This is expected behavior for the basic implementation
  • Advanced solution: implement message delimiters or reset signals

Build docs developers (and LLMs) love

Get started for freeTalk to us