On 12/04/2016 04:00 AM, Roman Shaposhnik wrote:
sendfile is a pretty Linux-centric API and I'm sure it isn't implemented by OSv.

OSv aims to be Linux compatible, and does implement sendfile() (though not without problems, as we see).

sendfile() originated in Solaris, IIRC, and variants exist in the BSDs as well.

Given that this is erlang and it must support platforms that don't
have sendfile(2)
I suggest you look into how to build it for POSIX (as opposed to
Linux) environment

Thanks,
Roman.

On Sat, Dec 3, 2016 at 5:06 PM, Rick Payne <ri...@rossfell.co.uk> wrote:
The erlang app that I’m hacking is sending out some data to a socket and its 
using sendfile to do this. This is causing OSv to abort:

(gdb) bt
#0  processor::cli_hlt () at arch/x64/processor.hh:248
#1  0x0000000000209cf6 in arch::halt_no_interrupts () at arch/x64/arch.hh:48
#2  0x000000000049983a in osv::halt () at arch/x64/power.cc:24
#3  0x000000000022d3c5 in abort (fmt=0xa1555d "Aborted\n") at runtime.cc:130
#4  0x000000000022d290 in abort () at runtime.cc:96
#5  0x00000000006a49c1 in osv::generate_signal (siginfo=..., 
ef=0xffff80007f40e068) at libc/signal.cc:128
#6  0x00000000006a4aa1 in osv::handle_mmap_fault (addr=35184720220160, sig=7, 
ef=0xffff80007f40e068) at libc/signal.cc:139
#7  0x00000000003c6363 in mmu::vm_sigbus (addr=35184720220160, 
ef=0xffff80007f40e068) at core/mmu.cc:1323
#8  0x00000000003c7715 in mmu::file_vma::fault (this=0xffffa0000d436c80, 
addr=35184720220160, ef=0xffff80007f40e068) at core/mmu.cc:1691
#9  0x00000000003c6513 in mmu::vm_fault (addr=35184720220160, 
ef=0xffff80007f40e068) at core/mmu.cc:1342
#10 0x00000000004899bb in page_fault (ef=0xffff80007f40e068) at 
arch/x64/mmu.cc:38
#11 <signal handler called>
#12 0x000000000047e905 in repmovsq (n=<optimized out>, src=<optimized out>, 
dest=<optimized out>) at arch/x64/string.cc:90
#13 memcpy_repmov_old_ssse3 (dest=0xffff800008898000, src=0x200014c01000, 
n=4096) at arch/x64/string.cc:270
#14 0x0000000000676d29 in uiomove (cp=0xffff800008898000, n=4096, 
uio=0x2000005e9c70) at fs/vfs/subr_uio.cc:62
#15 0x000000000023d78e in m_uiotombuf (uio=0x2000005e9c70, how=2, len=33397, 
align=0, min_size=2048, flags=0)
     at bsd/sys/kern/uipc_mbuf.cc:1847
#16 0x0000000000245753 in sosend_generic (so=0xffffa0000252e200, addr=0x0, 
uio=0x2000005e9c70, top=0x0, control=0x0, flags=0, td=0x0)
     at bsd/sys/kern/uipc_socket.cc:1047
#17 0x0000000000245ece in sosend (so=0xffffa0000252e200, addr=0x0, 
uio=0x2000005e9c70, top=0x0, control=0x0, flags=0, td=0x0)
     at bsd/sys/kern/uipc_socket.cc:1282
#18 0x0000000000253d41 in socket_file::write (this=0xffffa0000d1a1f80, 
uio=0x2000005e9c70, flags=0) at bsd/sys/kern/sys_socket.cc:91
#19 0x000000000067d3a0 in sys_write (fp=0xffffa0000d1a1f80, iov=0x2000005e9d10, 
niov=1, offset=-1, count=0x2000005e9d00)
     at fs/vfs/vfs_syscalls.cc:311
#20 0x000000000064c09a in pwrite (fd=31, buf=0x200014c00000, count=1073741823, 
offset=-1) at fs/vfs/main.cc:387
#21 0x000000000064c12b in write (fd=31, buf=0x200014c00000, count=1073741823) 
at fs/vfs/main.cc:405
#22 0x000000000064f003 in sendfile (out_fd=31, in_fd=32, 
_offset=0x2000023889e8, count=1073741823) at fs/vfs/main.cc:2051
#23 0x0000100001616d64 in efile_sendfile (errInfo=0x20000238894c, in_fd=32, 
out_fd=31, offset=0x2000023889e8, nbytes=0x2000005e9e78,
     hdtl=0x0) at drivers/unix/unix_efile.c:930
#24 0x000010000163527a in invoke_sendfile (data=0x200002388918) at 
drivers/common/efile_drv.c:1917
#25 0x00001000015a98eb in async_main (arg=0x20000098f0c0) at 
beam/erl_async.c:509
#26 0x00001000016c0615 in thr_wrapper (vtwd=0x2000001fe810) at 
pthread/ethread.c:114
#27 0x000000000069eebf in 
pthread_private::pthread::<lambda()>::operator()(void) const 
(__closure=0xffffa0007f39e700)
     at libc/pthread.cc:114
#28 0x00000000006a1a22 in std::_Function_handler<void(), 
pthread_private::pthread::pthread(void* (*)(void*), void*, sigset_t, const 
pthread_private::thread_attr*)::<lambda()> >::_M_invoke(const std::_Any_data &) 
(__functor=...) at /usr/include/c++/5/functional:1871
#29 0x000000000044cb1c in std::function<void ()>::operator()() const 
(this=0xffff80007f409070) at /usr/include/c++/5/functional:2267
#30 0x00000000005bfac4 in sched::thread::main (this=0xffff80007f409040) at 
core/sched.cc:1171
#31 0x00000000005bbca6 in sched::thread_main_c (t=0xffff80007f409040) at 
arch/x64/arch-switch.hh:164
#32 0x0000000000489793 in thread_main () at arch/x64/entry.S:113

It looks like the erlang code is calling sendfile with a large value (larger 
than the size of the actual file being sent). I see the sendfile code 
calculating the bytes to map, then mapping that area. It then crashes during 
the write:

930             retval = sendfile(out_fd, in_fd, offset, SENDFILE_CHUNK_SIZE);
#22 0x000000000064f003 in sendfile (out_fd=31, in_fd=32, 
_offset=0x2000023889e8, count=1073741823) at fs/vfs/main.cc:2051
2051        auto ret = write(out_fd, src + (offset % PAGESIZE), count);
(gdb) p/x count
$20 = 0x3fffffff

Any ideas?

Cheers,
Rick

--
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to