To begin with, note that argv is not necessarily the program name. It is what the caller puts into argv of the execve system call (e.g. see this question on Stack Overflow). (All other variants of exec are not system calls but interfaces to execve.)
Suppose, for instance, the following (using execl):
execl("/var/tmp/mybackdoor", "top", NULL);
When outputting to standard output using the C library's printf() function, the output is usually buffered. The buffer is not flushed until you output a newline, call fflush(stdout) or exit the program (not through calling _exit() though). The standard output stream is by default line-buffered in this way when it's connected to a TTY.
When you fork the ...
xxd has a mode for this. The -i/--include option will:
output in C include file style. A complete static array definition is written (named after the input file), unless xxd reads from stdin.
You can dump that into a file to be #included, and then just access foo like any other character array (or link it in). It also includes a declaration of the ...
Bash runs in POSIX mode when argv is sh. It runs as a login shell when argv begins with -.
Vim behaves differently when run as vi, view, evim, eview, ex, vimdiff, etc.
Busybox, as already mentioned.
In systems with systemd as init, shutdown, reboot, etc. are symlinks to systemctl.
and so on.
I think this part of the clone(2) man page may clear up the difference re. the PID:
CLONE_THREAD (since Linux 2.4.0-test8)
If CLONE_THREAD is set, the child is placed in the same thread
group as the calling process.
Thread groups were a feature added in Linux 2.4 to support the
POSIX threads notion of a ...
GNU/Linux systems usually use either glibc (Fedora/Redhat family, Arch) or its close cousin, eglibc (Debian/Ubuntu family); since eglibc is now being merged back into glibc (see EGLIBC 2.19 Branch Created under "News"), in the near future they will all be glibc again.
The easiest way to check the exact version is to ask ldd, which ships with the C library.
Actually, your virtual stack size is 8388608 bytes (8 MB). Of course, it's natural to conclude that this can't be right, because that's a ridiculously large amount of memory for every thread to consume for its stack when 99% of the time a couple of KB is probably all they need.
The good news is that your thread only uses the amount of physical memory that ...
You are right, indeed "something must have changed between 2001 and now". The book you are reading describes the world according to the first historical implementation of POSIX threads on Linux, called LinuxThreads (see also Wikipedia article for some).
LinuxThreads had some compatibility issues with POSIX standard - for example threads not sharing PIDs - ...
Historically, argv is just an array of pointers to the "words" of the commandline, so it makes sense to start with the first "word", which happens to be the name of the program.
And there's quite a few programs that behave differently according to which name is used to call them, so you can just create different links to them and get different "commands". ...
No, it doesn't, mainly for the reason that it doesn't require systems to conform by default, or to comply to only the POSIX standard (to the exclusion of any other standard).
For instance, Solaris (a certified compliant system) chose backward compatibility for its utilities in /bin, which explains why those behave in arcane ways, and provide POSIX-compliant ...
So you had a cow, but you inadvertently converted it to hamburger, and now you want your cow back.
Sorry, it just doesn't work that way.
Simply restore the source file from your backups.
Ah, you didn't have backups. Unfortunately, the universe doens't give you a break for that.
You can decompile the binary. That won't give you your source code, but it'll ...
What's happening in both cases is the same: to execute a file directly, the execute bit needs to be set, and the filesystem can't be mounted noexec. But these things don't stop anything from reading those files.
When the bash script is run as ./hello_world and the file isn't executable (either no exec permission bit, or noexec on the filesystem), the #! ...
In general, it’s not very different; there are lists of known pitfalls on the Hurd’s site and on the Debian wiki. Many projects build fine, or after a few fixes (the most common issue being the absence of PATH_MAX).
However in your case you’ll find it difficult to get anywhere: netfilter and iptables are specific to the Linux kernel, so you won’t be able to ...
If you know the definition of the data type you want you can use getconf to find these values out on most Unix systems.
$ getconf CHAR_BIT
The list of variables is defined in the man page man limits.h as well as here, man sysconf, in addition to being on disk. You can use locate limits.h to find it, it's often here: /usr/include/linux/limits.h.
System calls per se are a concept. They represent actions that processes can ask the kernel to perform.
Those system calls are implemented in the kernel of the UNIX-like system. This implementation (written in C, and in asm for small parts) actually performs the action in the system.
Then, processes use an interface to ask the system for the execution of ...
You can use the program name to change the program behavior.
For example you could create some symlinks to the actual binary.
One famous example where this technique is used is the busybox project which installs only one single binary and many symlinks to it. (ls, cp, mv, etc). They are doing it to save storage space because their targets are ...
In addition to programs altering their behaviour depending on how they were called, I find argv useful in printing the usage of a program, like so:
printf("Usage: %s [arguments]\n", argv);
This causes the usage message to always use the name through which it was called. If the program is renamed, its usage message changes with it. It even includes ...
(Userspace) threads are not implemented as processes as such on Linux, in that that they do not have their own private address space, they still share the address space of the parent process.
However, these threads are implemented to use the kernel process accounting system, so are allocated their own Thread ID (TID), but are given the same PID and 'thread ...
int pthread_attr_setstacksize(pthread_attr_t *attr, size_t stacksize);
The stacksize attribute shall define the minimum stack size (in
bytes) allocated for the created threads stack.
In your example, the stack size is set to 8388608 bytes which corresponds to 8MB, as returned by the command ulimit -s
So that matches.
From the pthread_create() ...
Modules can only access exported symbols, and exit_task_namespaces isn’t exported — so even though it is visible in the header files, it can’t be used in a module.
Exported symbols can be accessed as you’d expect, there’s nothing special to do.
C is an abstraction from the machine code that runs on the machine (although much closer than most other languages).
For those things machine code statements that cannot be expressed in C, and maybe for the extra optimization not provided by the C compiler assembly is used, mostly in the form of inline assembler.
In the kernel source code tree this is ...
It does not affect the fork in any way.
In the first case, you end up with 8 processes with nothing to write, because the output buffer was emptied already (due to the \n).
In the second case you still have 8 processes, each one with a buffer containing "Hello world..." and the buffer is written at process end.
A call to read() might result in more data being read behind the scenes than was requested (e.g. to read a full block from storage, or read ahead the following blocks), but read() itself never returns more data than was requested (count). If it did, the consequence could well be a buffer overflow since buf is often sized for only count bytes.
POSIX (see the ...
Here are the steps that almost guarantee to find what is leaking memory:
Find out the PID of the process which causing memory leak.
capture the /proc/PID/smaps and save into some file like BeforeMemInc.txt.
wait till memory gets increased.
capture again /proc/PID/smaps and save it has afterMemInc.txt
find the difference between first smaps and 2nd ...
I think memleax is exact what you want.
It debugs memory leak of a running process by attaching it, without recompiling program or restarting target process. It's very convenient and suitable for production environment.
It works on GNU/Linux and FreeBSD.
NOTE: I'm the author, any suggestion is welcome.
== EDIT ==
I also wrote another tool libleak, which ...
Your program does exactly what you tell it to do: it changes the working directory for itself to /home/enedil/projects/algo. But once it exits, the shell's working directory is restored.
I guess what you want to achieve is to change the working directory of the parent process, i.e. the shell, without resorting to a simple cd. There is a method, but as its ...
Here's a minimal example of modifying file descriptors of a spawned process, saved as foo.c:
int main(int argc, char* argv, char *env)
By including the WNOHANG option, you're telling waitpid() to not wait for the process to terminate if it hasn't already terminated.
My guess is that you added that because your program hangs if you don't include it. That's because the original parent still has an open file descriptor to the write-end of the pipe,...