linux-kernel - Query about coredump image generation for multi-threaded apps.

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>] [day] [month] [year] [list]

Date:	Thu, 6 Oct 2011 18:00:26 +0900
From:	"kautuk.c @samsung.com" <consul.kautuk@...il.com>
To:	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Cc:	chungki0201.woo@...sung.com
Subject: Query about coredump image generation for multi-threaded apps.

Dear All,

We are running a multi-threaded embedded application on a uniprocessor
ARM system.

We encountered a memory corruption due to which the application crashed.
The crashing thread accessed a pointer variable whose value was
corrupted and so the
application crashed.

However, there are multiple threads writing to that corrupted pointer
variable at the same instant
as the crash occurs on the crashing thread.
( As per the application logic, only proper writeable virtual memory
addresses are written to that
  variable, so this is a random corruption from some other module in
the process virtual address
  space. )

The result is that the coredump image generated does not contain the
same corrupted value inside
the pointer variable.

Also, various other variables' values are changed as a result of the
delay between the actual crash
and the actions of other threads on the shared global variables.

Query:
=====
Is there any way we can get the image of the process virtual memory in
the coredump at the exact time
of crash ?
Can someone describe possible solutions or workarounds to this problem
for both uniprocessor and SMP
systems ?

Note:
-------
I understand that this problem probably won't happen if we use a
pthread_mutex to protect those global
variables.
In that event, if there is a crash, the other threads will not be able
to access the shared global variables
as the mutex would not have been released.
However, this is currently not an option for us due to certain official reasons.
We would appreciate it if someone could find a way to solve this
without having to introduce any
pthread_mutexes.

Thanks,
Kautuk.
--
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/