[libcxx-dev] deque, block_size, __add_back_capacity

[Jason MacDonald via libcxx-dev]

I recompiled TI’s runtime library with the original block size from trunk and do not have issues.
So my question is, is a block size of 1 unsupported, and therefor the error is in TI’s changes? Or is there an error in _add_back_capacity()?

Why does __add_back_capacity(1) allocate more blocks if the base is empty, while __add_back_capacity() makes no check?

I’m talking about line 2510 of https://github.com/llvm-mirror/libcxx/blob/master/include/deque

FYI, w/o changes to TI’s code, as long as I resize(1) first, then push_back() will work just fine thereafter!
Somehow just that first push_back screws something up.

I really don’t want to have to run a modified version of TI’s runtime, but may have to.


From: Marshall Clow [mailto:mclow.lists at gmail.com]
Sent: Tuesday, April 2, 2019 4:04 PM
To: Jason MacDonald <jason.macdonald at ditchwitch.com>; libcxx-dev at lists.llvm.org
Subject: Re: [libcxx-dev] deque, block_size, __add_back_capacity


Think Before You Click: This email originated outside our organization.


On Tue, Apr 2, 2019 at 8:55 AM Jason MacDonald via libcxx-dev <libcxx-dev at lists.llvm.org<mailto:libcxx-dev at lists.llvm.org>> wrote:
Hello all,

First, apologizes if this is the wrong mailing list for this discussion.

This is not a terrible place.

 I am using the TI 18.1.5 compiler to compile for the TM4C1294NCPDT chip. A longer/better explanation of my problems might be obtained from the TI forums of my issue, which didn’t gain traction: https://e2e.ti.com/support/tools/ccs/f/81/t/787948<https://urldefense.proofpoint.com/v2/url?u=https-3A__e2e.ti.com_support_tools_ccs_f_81_t_787948&d=DwMFaQ&c=G4BpsyPyB19LB50bn2swXw&r=2z0vjupNNnhHhgc2c7HiUGlYDV8dSFvIGZRHV7-Giy8&m=cSTTEZftPo7skIefkh_qd4wKIAeJV3pt3zB7h5L7znY&s=rVckol1NRCLS5HnIfykH8Af8a5shQ8nmuu3jrU9rZZo&e=>
So I am trying to go upstream for more discussion.

Summary of my problem: Using deque::push_back on structures over 64 bytes will cause a crash.
Example code:
#include <deque>
struct s {
    char d[65];
};
int main()
{
    int size = sizeof(s);

    std::deque<s> test;
    test.push_back(s());
    test.push_back(s()); // will crash here
    while (1){}
}

I tried this on my desktop, and it did not crash.
I also turned on address sanitizer to see if there might be an out-of-bounds read or write, but it didn't report any.

I tried your second program (again, on my desktop), and added some printf statements, and I got:

back_spare  cap
61  62
61  62
62  62
62  62

TI’s implementation of the struct __deque_block_size allows a minimum size of 1. Not sure if this should cause a problem or not.
TI:
template <class _ValueType, class _DiffType>
struct __deque_block_size {
  enum __attribute__((__packed__)) { _MAX_BYTES = 32 * sizeof(void*) };
  static const _DiffType value = sizeof(_ValueType) < _MAX_BYTES ? (_MAX_BYTES / sizeof(_ValueType)) : 1;
};

So, is this a problem in LLVM’s __add_back_capacity() or TI’s block_size?

I'm suspecting TI's block_size.

here's the one from trunk:

template <class _ValueType, class _DiffType>
struct __deque_block_size {
  static const _DiffType value = sizeof(_ValueType) < 256 ? 4096 / sizeof(_ValueType) : 16;
};

Note that it never is smaller than 16.

-- Marshall

This email and any files transmitted with it from Charles Machine Works are confidential and intended solely for the use of the individual or entity to which they are addressed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20190402/2b9a879b/attachment-0001.html>