Re: Samsung Notebook: acpitz0 critical temp since sept 25 snapshot
On Thu, Oct 09, 2014 at 04:26:42PM -0700, Mike Larkin wrote: > On Thu, Oct 09, 2014 at 11:42:59PM +0200, Remi Locherer wrote: > > On Tue, Oct 07, 2014 at 10:10:54PM +0200, Remi Locherer wrote: > > > >Synopsis: Samsung Notebook: acpitz0 critical temp since sept 25 snapshot > > > >Environment: > > > System : OpenBSD 5.6 > > > Details : OpenBSD 5.6-current (GENERIC.MP) #399: Sun Oct 5 > > > 21:53:59 MDT 2014 > > > > > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > > > Architecture: OpenBSD.amd64 > > > Machine : amd64 > > > > > > >Description: > > > The Samsung 900X3F shuts down after boot with the message: > > > "acpitz0: critical temperature exceeded 144C, shutting down". The snapshot > > > from September 17 was working fine. Since snapshot September 25 I'm seeing > > > this. > > > > > > Strange thing: when I'm now booting the sept 17 snapshot kernel the > > > notebook > > > also shuts itselfe down with the above message. Does th kernel modify the > > > acpi tables? > > > > > > > Now this is really strange: today I booted the Samsung notebook several > > times with the kernel from snapshot oct 5. The problem with acpitz0 > > never occured. Can it be that the kernel sometimes is using a wrong > > address to read acpi stuff? Or is Samsung using a strange acpi > > implementation? > > > > Remi > > > > Try turning on debug and see what it's really reading. There are some > dprintfs in there > that will likely help. > > -ml > I figured out that to "fix" this issue once such a shutdown happens I have to leave the notebook turned off for some hours (usually I just suspend it). Should it happen again I'll compile a kernel with option ACPI_DEBUG and post the resulting dmesg. Remi
segfault in librthread with glib+gio (2.0)
Hi,
Initially, this problem was discover with www/vimb. But I have isolated
it, and it seems related to glib+gio with/or librthread. The mail is
cross-posted to ports@ (if glib+gio is the problem) and bugs@ (if the
problem is with librthread).
I run openbsd -current (GENERIC.MP) under amd64.
For vimb, calling:
$ vimb -C "sh xterm"
will generate a "vimb.core" in cwd.
The segfault occurs at fork() (in librthead) in the child process (the
window of vimb stay here: it is the child that segfault).
Here a minimal c-file that reproduce the problem:
BEGIN test.c
/*
* cc test.c -o test `pkg-config -cflags -libs glib-2.0 gio-2.0`
*/
#include
#include
#include
#include
int main(int argc, char *argv) {
char *stdOut = NULL, *stdErr = NULL;
int status;
GError *error = NULL;
g_tls_file_database_new("/etc/ssl/cert.pem", &error);
if (error) {
printf("could not load ssl database: %s\n", error->message);
g_error_free(error);
return(EXIT_FAILURE);
}
if (FALSE == g_spawn_command_line_sync("xterm", &stdOut, &stdErr,
&status, &error)) {
printf("can't run cmd: %s\n", error ? error->message :
"(null)");
g_clear_error(&error);
return(EXIT_FAILURE);
}
return(EXIT_SUCCESS);
}
END test.c
Here a commented gdb session (and an explaination below):
$ gdb ./test
## the segfault occurs in child, so follow the child
(gdb) set follow-fork-mode child
## track when the "bad data" is setted
(gdb) br pthread_atfork
Function "pthread_atfork" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (pthread_atfork) pending.
## run the program
(gdb) r
Starting program: /home/semarie/tmp/src/test-gio/test
Breakpoint 2 at 0x10e3aaf73840: file /usr/src/lib/librthread/rthread_fork.c,
line 179.
Pending breakpoint "pthread_atfork" resolved
## the "bad data" will be 0x10e356d3ae40 (child argument)
## the backtrace don't saw useful information... be we are somewhere in
## g_tls_file_database_new() call (when loading giomodule for tls).
Breakpoint 2, pthread_atfork (prepare=0, parent=0, child=0x10e356d3ae40) at
/usr/src/lib/librthread/rthread_fork.c:179
179 {
(gdb) bt
#0 pthread_atfork (prepare=0, parent=0, child=0x10e356d3ae40) at
/usr/src/lib/librthread/rthread_fork.c:179
#1 0x10e3aaf7128e in pthread_once (once_control=0x10e356f55f40,
init_routine=0x10e356d3aef0)
at /usr/src/lib/librthread/rthread_once.c:26
#2 0x10e356d08eae in ?? ()
#3 0x in ?? ()
## the "bad data" is not bad here: we could access it.
(gdb) print *0x10e356d3ae40
$1 = 1761971016
## there is some others call to pthread_atfork, skip them
(gdb) disable
(gdb) continue
Continuing.
[New process 21972]
Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 1028857]
0x10e356d3ae40 in ?? ()
## ok, we try to access the "bad data"
## we are *after* the fork occurs (see New process)
(gdb) bt
#0 0x10e356d3ae40 in ?? ()
#1 0x10e3aaf73afb in fork () at /usr/src/lib/librthread/rthread_fork.c:160
#2 0x10e368f2b72c in fork_exec_with_pipes () from
/usr/local/lib/libglib-2.0.so.4200.0
#3 0x10e368f2c55c in g_spawn_sync () from
/usr/local/lib/libglib-2.0.so.4200.0
#4 0x10e368f2ca6a in g_spawn_command_line_sync () from
/usr/local/lib/libglib-2.0.so.4200.0
#5 0x10e0b9200fbb in main () from /home/semarie/tmp/src/test-gio/test
## the "bad data" is not accessible
(gdb) print *0x10e356d3ae40
Cannot access memory at address 0x10e356d3ae40
Somewhere in loading some giomodule in g_tls_file_database_new call,
pthread_atfork is called with child=0x10e356d3ae40. At this time, the
memory address is accessible (gdb print command works).
When g_spawn_command_line_sync is called, after the fork (we are in the
child process), the memory address 0x10e356d3ae40 is not accessible
anymore.
I don't known where to search now... the problem could be related to
librthread, or the use of glib+gio. Any help is welcome.
Thanks.
--
Sébastien Marie
Re: segfault in librthread with glib+gio (2.0)
Hi Dmitrij,
> Apparently I have similar problem with surf:
You could try to workaround by launching surf with:
$ LD_PRELOAD=/usr/local/lib/gio/modules/libgiognutls.so surf
For vimb, it works.
About the problem, my last "minimal c-file" looks like:
/*
* cc test.c -o test `pkg-config -cflags -libs glib-2.0 gio-2.0`
*/
#include
#include
#include
#include
int main(int argc, char *argv) {
//g_module_open("/usr/local/lib/gio/modules/libgiognutls.so",
G_MODULE_BIND_MASK);
g_tls_backend_get_default ();
fork();
return(EXIT_SUCCESS);
}
The g_module_open function is called near the pthread_atfork in
g_tls_backend_get_default.
But:
- only with it (g_module_open + fork): no problem
- with g_module_open+g_tls_backend_get_default+fork: no problem
So there is something between the two...
the g_module_open (in g_tls_backend_get_default) will call:
_g_module_open (file_name=0x15887c4669c0
"/usr/local/lib/gio/modules/libgiognutls.so", bind_lazy=1, bind_local=1) at
gmodule-dl.c:97
which call dlopen().
the pthread_atfork seems (but not sure) to be part of dlopen in the
pthread case.
--
Sébastien Marie
[PATCH] 56.html missing word "equally"
Index: 56.html === RCS file: /cvs/www/56.html,v retrieving revision 1.46 diff -u -p -u -r1.46 56.html --- 56.html 11 Oct 2014 03:03:01 - 1.46 +++ 56.html 13 Oct 2014 16:38:55 - @@ -243,7 +243,7 @@ time_t values outside that range are sto Faster hibernate/unhibernate performance on amd64 and i386 platforms. Support hibernating to http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man4/softraid.4";>softraid(4) crypto volumes. Added http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man3/reallocarray.3";>reallocarray(3), -which allows multiple sized objects to be allocated without the cost of +which allows multiple equally sized objects to be allocated without the cost of clearing memory while avoiding possible integer overflows. Extended http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man3/fread.3";>fread(3) and http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man3/fwrite.3";>fwrite(3)
Re: segfault in librthread with glib+gio (2.0)
On Mon, 13 Oct 2014, Sébastien Marie wrote: > Initially, this problem was discover with www/vimb. But I have isolated > it, and it seems related to glib+gio with/or librthread. The mail is > cross-posted to ports@ (if glib+gio is the problem) and bugs@ (if the > problem is with librthread). The dlopen()ed gnome-keyring-pkcs11.so calls pthread_atfork() with a function pointer from itself. Later, it gets dlclose()d and unloaded, leaving this a dangling pointer. glibc's pthread_atfork() is like atexit(): it records the __dso_handle of the caller and on unload of a shared object they unregister all atfork handlers registered by that shared object. :-( Philip
