Comment 1:

if you simply want to trigger that message, you can use this:
package main
/*
#include <pthread.h>
void *
pauser(void *x) {
        *(int *)0 = 1;
    return 0;
}
void
startThread(void) {
    pthread_t p;
    pthread_create(&p, 0, pauser, 0);
}
*/
import "C"
func main() {
    C.startThread()
    for {}
}

Comment 2:

the reason why we haven't already implement your suggestion is that
when we received a signal on non-Go-created thread, we don't have
access to m & g so we can't reliably call runtime.printf.
i agree we can do better.

Status changed to Accepted.

Comment 3:

Attached is my attempt at a fix but the call to findnull (strlen) on the signal name
string causes it to exceed the nosplit stack limit check.
Three ways to proceed:
(a) expand the amount stack available.  Seems like a sledgehammer to crack a nut.
(b) compute strlen of the string literals and save it as another column in sigtab.
(b) do nothing (or wait till the compiler's register allocation improves).
Go experts: please advise.

Attachments:

1. 4048.patch (4957 bytes)

Comment 4:

This is a case that will approximately never happen.  Since the argument is not nil,
findnull is two lines long.  I would just inline it.

Comment 5:

Labels changed: added priority-later, removed priority-triage.

Comment 6:

Labels changed: added go1.1.

Comment 7:

Alan, your patch looks fine except that it should make sure 0 <= sig && sig <
nelem(runtime·sigtab) before doing the print (and inline findnull as Ian said). Want to
send a CL?

Comment 8:

Labels changed: added size-m.

Comment 9:

There's not enough space in the frame for even one extra pointer variable, so inlining
findnull doesn't help.

Comment 10:

yeah, i also tried to fix this issue, and stuck by the same obstacle.
can we use a function pointer to work around the linker's check of
maximum stack frame for non-split functions?
as the function in question should always be called on a OS thread
stack, so the stack space is plenty.

Comment 11:

It worked!
https://golang.org/cl/7232066

Comment 12:

This issue was closed by revision e49f945.

Status changed to Fixed.