Bug 200617 - exec silently fails if text_size > maxtsiz
Summary: exec silently fails if text_size > maxtsiz
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-bugs (Nobody)
Depends on:
Reported: 2015-06-03 16:22 UTC by Ed Maste
Modified: 2019-01-21 17:55 UTC (History)
3 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Ed Maste freebsd_committer 2015-06-03 16:22:51 UTC
I tried to run a debug build of Chrome:

feynman% ./chrome
zsh: abort      ./chrome

There's no log message on the console or in /var/log/messages.

LLDB is no help:

feynman% lldb ./chrome
Current executable set to './chrome' (x86_64).
(lldb) run
Process 25332 launching
failed to fetch ps_strings: No such process
Process 25332 stopped
(lldb) error: initial process state wasn't stopped: exited

GDB is no help:

feynman% gdb79 ./chrome 
GNU gdb (GDB) 7.9 [GDB v7.9 for FreeBSD]
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd10.1".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
Find the GDB manual and other documentation resources online at:
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./chrome...(no debugging symbols found)...done.
(gdb) run
Starting program: /tank/emaste/src/ports/www/chromium/chrome 
During startup program terminated with signal SIGABRT, Aborted.

If one knows what to look for dtrace is helpful:

dtrace: description 'fbt:kernel:exec_elf64_imgact:return ' matched 1 probe
CPU     ID                    FUNCTION:NAME
  4  13890         exec_elf64_imgact:return error=12

That's ENOMEM. From imgact_elf.c:

        if (data_size > lim_cur(imgp->proc, RLIMIT_DATA) ||
            text_size > maxtsiz ||
            total_size > lim_cur(imgp->proc, RLIMIT_VMEM) ||
            racct_set(imgp->proc, RACCT_DATA, data_size) != 0 ||
            racct_set(imgp->proc, RACCT_VMEM, total_size) != 0) {
                return (ENOMEM);

This case should produce some sort of user-facing log message (likely from kern_execve, not imgact_elf).

         *      Loop through the list of image activators, calling each one.   
         *      An activator returns -1 if there is no match, 0 on success,    
         *      and an error otherwise.
        for (i = 0; error == -1 && execsw[i]; ++i) {
                if (execsw[i]->ex_imgact == NULL ||
                    execsw[i]->ex_imgact == img_first) {
                error = (*execsw[i]->ex_imgact)(imgp);

        if (error) {
                if (error == -1) {
                        if (textset == 0)
                        error = ENOEXEC;
                goto exec_fail_dealloc;
Comment 1 Ed Maste freebsd_committer 2015-06-03 20:13:24 UTC
Comment 2 commit-hook freebsd_committer 2015-06-08 16:07:20 UTC
A commit references this bug:

Author: emaste
Date: Mon Jun  8 16:07:08 UTC 2015
New revision: 284157
URL: https://svnweb.freebsd.org/changeset/base/284157

  Add user facing errors for exceeding process memory limits

  Previously the process terminating with SIGABRT at startup was the
  only notification.

  PR:		200617
  Reviewed by:	kib
  Sponsored by:	The FreeBSD Foundation
  Differential Revision: https://reviews.freebsd.org/D2731

Comment 3 Tony Narlock 2015-07-13 17:34:12 UTC

I'm at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196770 and have been able to build chromium-43.0.2357.132, but still get the empty binary issue.

I'm on 10.2-BETA. 

Does this fix apply to the chromium bug?

Could this patch  work on 10.1-STABLE?   Is there any sort of debug info I could provide to help?
Comment 4 Oleksandr Tymoshenko freebsd_committer freebsd_triage 2019-01-21 17:55:20 UTC
There is a commit referencing this PR, but it's still not closed and has been inactive for some time. Closing the PR as fixed but feel free to re-open it if the issue hasn't been completely resolved.