Marcos Dione | 24 Nov 21:34 2014
Picon

mmap'ed robust mutexes and possible undefined behaviour

        Hello everybody. First of all, I'm not subscribed to the mailing 
list, so please CC me any responses.

        We found a situation where a robust mutex cannot be recovered
from a stale lock and we're wondering if it's simply an undefined
situation or  a bug in the kernel. Attached you will find the sample
code, which is loosely based on a glibc's test case.The gist of it is as
follows:

1. we open a file.
2. we mmap it and use that mem to store a robust mutex.
3. we lock the mutex.
4. we munmap the file.
5. we close the file.

        The example does steps 1 and 2, then creates creates tw children
who will try  to do steps 3 to 5. Of course only one gets the lock while
the other waits. If the child who  has the lock does the 4th step, then
the other child never recovers the stale lock. In any  other situation
(that is, commenting/removing the code) it works fine.

    This looks suspiciously like undefined behaviour, because it's like
we're pulling  the rug from under the mutex' feet, but in the other hand
looks like a kernel bug because  it doesn't really recover from the
situation. What do you think? 

--

-- 
(Not so) Random fortune:
22:22 < m4rgin4l_> hendrix no tocaba la viola, violaba la toca
(Continue reading)

Eng cent | 19 Nov 20:50 2014
Picon

getopt_long takes an option as an argument of another option which requires argument

Hi!
I need help in explaining one of the behavior of getopt_long, where an
option requires an argument, but unfortunately it is followed by
another option, thus that option becomes the argument, and getopt_long
does not raise error.

I want to understand if this is by standard or a bug in getopt_long
(glibc). I wrote a sample program on Redhat (Red Hat Enterprise Linux
Server release 5.8 (Tikanga)), and glic 2.0.

For the sample program,

1. To compile
   gcc -g -o getopttest getoptlong.c
2. To run
   ./getopttest -c -d -d

Then you will see the first '-d' becomes the value of "-c" in the
console output:

$ ./getopttest -c -d -d
option c with value '-d'
option d

If I NM the symbol,
$ nm geto | grep getopttest
$ U getopt_long <at>  <at> GLIBC_2.0

It shows glibc 2.0.

(Continue reading)

Stephan Bergmann | 19 Nov 12:14 2014
Picon

Type of FD_ISSET happens to be bool in C++

While SUS mandates FD_ISSET to have return type int (in C, which is all 
SUS is concerned with), the definition

> #define __FD_ISSET(d, set) \
>   ((__FDS_BITS (set)[__FD_ELT (d)] & __FD_MASK (d)) != 0)

in bits/select.h causes it to have type bool instead in C++.  Is that by 
design or by accident?

MaShimiao | 19 Nov 08:15 2014

thread safety level of fwide

Hi, everyone

fwide() is annotated as 
Preliminary: | MT-Safe | AS-Unsafe corrupt | AC-Unsafe lock 
in the glibc manual.

After reading it's source code, I think it should be marked with race:stream.
The reasoning is fwide() uses fp several times inside without holding the lock over all of them.

How do you think about that?

The fwide()'s code is as follows:
int
fwide (fp, mode)
     _IO_FILE *fp;
     int mode;
{
  int result;

  /* Normalize the value.  */
  mode = mode < 0 ? -1 : (mode == 0 ? 0 : 1); 

  if (mode == 0 || fp->_mode != 0)
    /* The caller simply wants to know about the current orientation
       or the orientation already has been determined.  */
    return fp->_mode;

  _IO_acquire_lock (fp);
  result = _IO_fwide (fp, mode);
  _IO_release_lock (fp);
(Continue reading)

Ivan Zaigralin | 17 Nov 18:01 2014

concerning headers, glibc, and kernel upgrades

Hi! I am in the process of de-blobbing Slackware, and one of my basic
tasks consists in replacing the stock kernel with Linux-libre kernel.
Not content with merely de-blobbing the kernel, I would like to explore
the option of upgrading it, but then some questions arise.

Please excuse me if my questions are confusing or ill-informed, as I
lack expertise in kernel-related issues.

My question concerns the interplay between Linux-libre, glibc, and
the so-called kernel headers used by glibc. The wiki says:

> The headers from the most recent Linux kernel should be used. The
> headers used while compiling the GNU C library and the kernel
> binary used when using the library do not need to match. The GNU
> C library runs without problems on kernels that are older than
> the kernel headers used. The other way round (compiling the GNU C
> library with old kernel headers and running on a recent kernel)
> does not necessarily work as expected. For example you can't use
> new kernel features if you used old kernel headers to compile the
> GNU C library.

> Even if you are using an older kernel on your machine, we
> recommend you compile GNU libc with the most current kernel
> headers.  That way you won't have to recompile libc if you ever
> upgrade to a newer kernel.

So let's say glibc is built against kernel headers 3.18.* and the kernel
in use is 3.10.17. So there is a version mismatch. Isn't it possible that
some interface is different, like some struct has changed size, and then
glibc calls to kernel (or some other app calls through gibc) and kaboom?
(Continue reading)

Toby Gray | 14 Nov 11:03 2014

How thread safe is dlopen?

Hello,

I've come across an issue with my use of dlopen and pthreads in my code 
and glibc 2.19. Using valgrind I've tracked it down to the following issue:

==00:00:00:05.063 23870== Thread 30:
==00:00:00:05.063 23870== Invalid write of size 8
==00:00:00:05.063 23870==    at 0x04012d4c: _dl_allocate_tls_init 
(dl-tls.c:417)
==00:00:00:05.063 23870==    by 0x05043715: pthread_create <at>  <at> GLIBC_2.2.5 
(allocatestack.c:252)
==00:00:00:05.063 23870==    by 0x00400e44: thread_function (within 
/home/tg/tmp/MOB-11244/a.out)
==00:00:00:05.063 23870==    by 0x05043181: start_thread 
(pthread_create.c:312)
==00:00:00:05.063 23870==    by 0x05353fbc: clone (clone.S:111)
==00:00:00:05.063 23870==    Address 0x64fbad0 is 0 bytes after a block 
of size 272 alloc'd
==00:00:00:05.063 23870==    at 0x04c2cc70: calloc (in 
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==00:00:00:05.063 23870==    by 0x04012e54: _dl_allocate_tls (dl-tls.c:296)
==00:00:00:05.063 23870==    by 0x05043da0: pthread_create <at>  <at> GLIBC_2.2.5 
(allocatestack.c:589)
==00:00:00:05.063 23870==    by 0x00400e44: thread_function (within 
/home/tg/tmp/MOB-11244/a.out)
==00:00:00:05.063 23870==    by 0x05043181: start_thread 
(pthread_create.c:312)
==00:00:00:05.063 23870==    by 0x05353fbc: clone (clone.S:111)
==00:00:00:05.063 23870==

(Continue reading)

MaShimiao | 14 Nov 01:24 2014

question about race:stream in glibc manual

Hi Carlos, Alexandre

I'm Ma Shimiao.
I'm a bit new to glibc.
I have a question about glibc manual, could you help me?

The glib manual says,
if a function annotated with race, it should operate on objects in ways that may cause
data races or similar forms of destructive interference out of concurrent execution.
In some cases, the objects are passed to the functions by users;
in others, they are used by the functions to return values to users;
in others, they are not even exposed to users.
We consider access to objects passed as (indirect) arguments to functions to be data
race free. The assurance of data race free objects is the caller’s responsibility. We
will not mark a function as MT-Unsafe or AS-Unsafe if it misbehaves when users fail
to take the measures required by POSIX to avoid data races when dealing with such
objects.

According to the manual, I think if a function has an argument FILE *stream and the stream
may cause data races inside the function, it should annotated with MT-Safe race:stream.
Am I right?

Best regards, 

--

-- 
Ma Shimiao
Development Dept.I
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)

(Continue reading)

Ma Shimiao | 13 Nov 16:34 2014
Picon

question about race:stream in glibc manual

Hi, everyone

I'm Ma Shimiao.
I'm a bit new to glibc.
I have a question about glibc manual, could you help me?

The glib manual says,
if a function annotated with race, it should operate on objects in ways that may cause
data races or similar forms of destructive interference out of concurrent execution.
In some cases, the objects are passed to the functions by users;
in others, they are used by the functions to return values to users;
in others, they are not even exposed to users.
We consider access to objects passed as (indirect) arguments to functions to be data
race free. The assurance of data race free objects is the caller’s responsibility. We
will not mark a function as MT-Unsafe or AS-Unsafe if it misbehaves when users fail
to take the measures required by POSIX to avoid data races when dealing with such
objects.

According to the manual, I think if a function has an argument FILE *stream and the stream
may cause data races inside the function, it should annotated with MT-Safe race:stream.
Am I right?

Best regards,

nick | 13 Nov 00:54 2014
Picon

Help With School Assignment

Greetings other developers,
	I am having some issues with these rather simple program due to be over thinking it and it would be
great to get some fresh eyes. In addition I am pasting my code below with a link to my professor's page for the
assignment. I just really need help with the genSudokuBoard function the others as you can I have finished already
and work fine.
Cheers Nick
https://scs.senecac.on.ca/~danny.abesdris/
/*a3Primer.c
   date:    november 3, 2014
   author:  danny abesdris
   purpose: primer for ipc144 (fall 2014) assignment #3
            including solution to the
            void genSudokuNumbers(int grid[ ]) function.
*/

#include <stdio.h>
#include <time.h>
#include <stdlib.h>

#define N 9
/* NOTE: You will have to code the 2 functions BELOW "checkDups" and "clearArray"
         before running this program to see the generated output.
*/
int checkDups(int [ ], int, int);
void clearArray(int [ ], int);

int genSudokuNumbers(int grid[ ]); /* already coded */

void genSudokuBoard(int grid[ ], int display[ ]);
void displaySudokuBoard(int display[ ], int bigOh);
(Continue reading)

Eric Sanchis | 1 Nov 14:49 2014
Picon

Copying and concatenating strings with str5 functions

Dear maintainers,

Today, string copy/concatenation remains a problem. I suggest an
alternative to strncpy/strncat (strn) and strlcpy/strlcat (strl)
functions.

Str5cpy/str5cat functions are:
- C89 compliant
- Safer and easier to use than strn/strl functions
- Transparent (no silent unwanted behaviour) and orthogonal (uniform behaviour).

They return a meaningful return value and produce auto-documented source code.

Please, take a look to the str5 functions and the companion document:

http://aral.iut-rodez.fr/en/sanchis/miscellaneous/str5/str5.html

Using strcpy/strcat in simple cases and str5cpy/str5cat in tricky
situations could be a good compromise.

Sincerely yours,

Eric Sanchis
University of Toulouse Capitole (IUT de Rodez)

Christer Solskogen | 31 Oct 23:26 2014
Picon

Shared-only glibc

Would that even be possible? No static libraries at all.


Gmane