linux-kernel - SIGBUS caused by mmap and memcpy that doesn't go away after application restart

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTings_UPY4xSGe39X3GB8g9V=betWASk9YhspiTN@mail.gmail.com>
Date:	Mon, 20 Dec 2010 16:08:21 -0700
From:	AJ ONeal <coolaj86@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: SIGBUS caused by mmap and memcpy that doesn't go away after
 application restart

After posting to my local LUG I was told to ask about the possibility
of a kernel bug here


I have an application which runs for several hours in the same loop
correctly, but eventually dies with SIGBUS.

If I try to start the application again it immediately exits with
SIGBUS and will not work until rebooted.

gdb reports
Program received signal SIGBUS, Bus error.
0x401bd354 in memcpy () from /lib/libc.so.6
(gdb) bt
#0  0x401bd354 in memcpy () from /lib/libc.so.6
#1  0x0000929c in capture_file_write ()
#2  0x0fefeb0a in ?? ()
#3  0x0fefeb0a in ?? ()

Any ideas on what causes this error?
How do I go about finding what #2 and #3 are?


The system is a ARM OMAP3530 (Gumstix Overo). The kernel is 3.6.36.

This is the application flow:

count = 0
do
    outfile = /dev/shm/output.{#count}.dat
    data = read logged.dat for 512kb
    unlink outfile if exists
    truncate outfile to 512kb
    outfile_p = mmap outfile
    memcpy data outfile_p
    munmap
    count += 1
    if count > MAX; count = 0
    advance or rewind logged.dat
loop

I can post a link to a gist of the source upon request.

AJ ONeal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/