What is wrong with dtrace's stack()?

[Lev Serebryakov]

On 24.10.2018 18:48, Ryan Stone wrote:
> sosend_generic+0x112c is the return address, so it's one instruction
> after the call instruction that called lock_delay.
  Yes, but this instruction (+0x112b) calls real protocol send function
via function pointer.

> What's the line number of sosend_generic+0x112b?

 It is here, uipc_socket.c:1589:

	error = (*so->so_proto->pr_usrreqs->pru_send)(so,
	    (flags & MSG_OOB) ? PRUS_OOB :
	/*
	 * If the user set MSG_EOF, the protocol understands
	 * this flag and nothing left to send then use
	 * PRU_SEND_EOF instead of PRU_SEND.
	 */
	    ((flags & MSG_EOF) &&
	     (so->so_proto->pr_flags & PR_IMPLOPCL) &&
	     (resid <= 0)) ?
		PRUS_EOF :
	/* If there is more to send set PRUS_MORETOCOME. */
	    (flags & MSG_MORETOCOME) ||
	    (resid > 0 && space > 0) ? PRUS_MORETOCOME : 0,
	    top, addr, control, td);

 I have these three DIFFERENT stack, which should be one for sure, as it
is confirmed by custom SDT probes now (I've added them and checked).
Addresses are different from previous examples due to some code was
shifted by SDT probes. 26462 times stack is Ok, but 4068+3993 times some
frames are lost. Same address could not call both tcp_usr_send() and
ia32_pause() and lock_delay(). Really, it should be one stack trace!

              kernel`lock_delay+0x72
              kernel`sosend_generic+0xf61
              kernel`sosend+0x79
              kernel`soo_write+0x6b
              kernel`fo_write+0x4a
              kernel`dofilewrite+0xcd
              kernel`kern_writev+0x79
              kernel`sys_write+0x8f
              kernel`syscallenter+0x774
              kernel`amd64_syscall+0x1b
              kernel`0xffffffff80cedfbd
             3993

              kernel`ia32_pause+0x7
              kernel`sosend_generic+0xf61
              kernel`sosend+0x79
              kernel`soo_write+0x6b
              kernel`fo_write+0x4a
              kernel`dofilewrite+0xcd
              kernel`kern_writev+0x79
              kernel`sys_write+0x8f
              kernel`syscallenter+0x774
              kernel`amd64_syscall+0x1b
              kernel`0xffffffff80cedfbd
             4068

              kernel`ia32_pause+0x6
              kernel`tcp_usr_send+0x131
              kernel`sosend_generic+0xf61
              kernel`sosend+0x79
              kernel`soo_write+0x6b
              kernel`fo_write+0x4a
              kernel`dofilewrite+0xcd
              kernel`kern_writev+0x79
              kernel`sys_write+0x8f
              kernel`syscallenter+0x774
              kernel`amd64_syscall+0x1b
              kernel`0xffffffff80cedfbd
            26462

> On Tue, Oct 23, 2018 at 5:34 PM Lev Serebryakov <lev at freebsd.org> wrote:
>>
>> Hello Ryan,
>>
>> Monday, October 22, 2018, 11:50:29 PM, you wrote:
>>
>>> Adding -fno-optimize-sibling-calls to the compiler flags will eliminate the TCO.
>>  Stacks are better but still strange. For example I have such stack (which I
>>  like better than previous):
>>
>>  kernel`lock_delay+0x72
>>  kernel`sosend_generic+0x112c
>>  kernel`sosend+0x79
>>  kernel`soo_write+0x6b
>>  kernel`fo_write+0x4a
>>  kernel`dofilewrite+0xcd
>>  kernel`kern_writev+0x79
>>  kernel`sys_write+0x8f
>>  kernel`syscallenter+0x774
>>  kernel`amd64_syscall+0x1b
>>  kernel`0xffffffff80cebf6d
>>
>> According to addr2line `sosend_generic+0x112c' is
>>
>> https://svnweb.freebsd.org/base/head/sys/kern/uipc_socket.c?revision=339419&view=markup#l1579
>>
>>  Which is call to protocol-specific send function. Where is this function
>> (it should be tcp for sure)?!
>>
>> --
>> Best regards,
>>  Lev                            mailto:lev at FreeBSD.org
>>
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
> 


-- 
// Lev Serebryakov

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20181024/800d6b3e/attachment.sig>