bugGNU troff - Bugs: bug #48433, lkbib with empty file dumps core


bug #48433: lkbib with empty file dumps core

Submitter:  Osamu Sayama <sayama>
Submitted:  Thu 07 Jul 2016 07:02:31 AM UTC
Category:  Preprocessor refer Severity:  3 - Normal
Item Group:  Crash/Unresponsive Status:  Fixed
Privacy:  Public Assigned to:  carstenkunze
Open/Closed:  Closed Planned Release:  1.22.4
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:
       No canned response available


Tue 01 Mar 2022 02:07:12 PM UTC, comment #2: 

commit 2ac1f9ba5578cad27dc547d5be3c91753db436ea
Author: Osamu Sayama <sayama>
Date:   Fri Apr 28 23:56:15 2017 +0200

    lkbib with empty file dumps core

    See https://savannah.gnu.org/bugs/?48433

G. Branden Robinson <gbranden>
Project Administrator
Sat 25 Jul 2020 06:46:39 AM UTC, comment #1: 

Fixed in commit 2ac1f9ba5578cad27dc547d5be3c91753db436ea back on 2017-04-28.

G. Branden Robinson <gbranden>
Project Administrator
Thu 07 Jul 2016 07:02:31 AM UTC, original submission:  

In Solaris, I got the bug report that lkbib dumps core with the following operation.
% touch ./a.i
% LD_PRELOAD=libumem.so.1 UMEM_OPTIONS=backend=mmap \
UMEM_DEBUG=default,firewall=1 /usr/bin/lkbib -p ./a
Segmentation Fault (core dumped)
% pstack core
core 'core' of 1509:    /usr/bin/lkbib -p ./a
 00000000004094fa _1cRindex_search_itemEload6Mi_i () + 10a
 0000000000409ad0 _1cWmake_index_search_item6Fpkci_pnLsearch_item_ () + e0
 000000000040ea47 _1cLsearch_listIadd_file6Mpkci_v () + 27
 0000000000408614 main () + f4
 00000000004083a4 ???????? ()

Then it looks that this core dump occurs at the following point.
int index_search_item::load(int fd)
  mtime = sb.st_mtime;
  int size = int(sb.st_size);                           <= size is 0
  map_addr = mapread(fd, size);
  else {
    addr = buffer = (char *)malloc(size);               <= malloc(0)
  header = (index_header )addr;                       <= Segv

From the specification of malloc() in the standard (ex, C11),
I can see C11 draft version from
p 347 7.22.3 Memory management functions
If the size of the space requested is zero, the behavior is
implementation-defined: either a null pointer is returned, or the behavior
is as if the size were some nonzero value, except that the returned pointer
shall not be used to access an object.
There is the possibility that it returns pointer shall not be used to access
an object on some platform. So I think it's nice to check the size of file
to avoid core dump.
--- groff-1.22.3/src/libs/libbib/index.cpp.org  2014-11-04 17:38:35.183524522 +0900
+++ groff-1.22.3/src/libs/libbib/index.cpp      2016-07-07 09:41:11.572149218 +0900
@@ -158,6 +158,10 @@
   mtime = sb.st_mtime;
   int size = int(sb.st_size);
+  if (size == 0) {
+    error("`%1' is an empty file", name);
+    return 0;
+  }
   char *addr;
   map_addr = mapread(fd, size);
   if (map_addr) {

Osamu Sayama <sayama>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by gbranden (Posted a comment)
  • -email is unavailable- added by carstenkunze (Updated the item)
  • -email is unavailable- added by sayama (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.





    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-06-15 gbranden CategoryNone Preprocessor refer
    2020-07-25 gbranden StatusReady For Test Fixed
        Open/ClosedOpen Closed
        Planned ReleaseNone 1.22.4
    2017-04-28 carstenkunze StatusNone Ready For Test
        Assigned toNone carstenkunze

    Back to the top

    Powered by Savane 3.9