Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix a exception during De-Serialize #8

Open
vishwabmc opened this issue Oct 11, 2017 · 5 comments
Open

Fix a exception during De-Serialize #8

vishwabmc opened this issue Oct 11, 2017 · 5 comments

Comments

@vishwabmc
Copy link
Contributor

While trying to De-Serialize a Non-versioned Cereal object from a versioned Cereal code, saw that it raised std::length_error exception as opposed to a CerealException and that is indicating an issue in the code that handles the vectors. May be association ?

terminate called after throwing an instance of 'std::length_error'
  what():  vector::_M_default_append

See : USCiLab/cereal#192

@ghost
Copy link

ghost commented Mar 25, 2018

I have a similar issue but with a value error.

ValueError: vector::_M_default_append

@vishwabmc Have you solved this ?

@michalglen
Copy link

michalglen commented May 16, 2019

Hi all,
I also have the same issue when trying to deserialize using Cereal
terminate called after throwing an instance of 'std::length_error' what(): vector::_M_default_append
@vishwabmc @zaouch
Did you manage to fix it?

@guozhizou
Copy link

Got exactly the same issue, any solutions?

@spinler
Copy link
Contributor

spinler commented Sep 11, 2019

@guozhizou This happened in phosphor-logging code?

@guozhizou
Copy link

Not phosphor-logging but similar situation with USCiLab/cereal#192

geissonator pushed a commit that referenced this issue Oct 1, 2024
On newer libstdc++ implementations, the following backtrace is
observed:

```
 #2  0x00007ffff7a578b7 in abort () from /usr/lib64/libc.so.6
 #3  0x00007ffff7cda2af in std::__glibcxx_assert_fail(char const*, int, char const*, char const*) () from /usr/lib/gcc/x86_64-pc-linux-gnu/14/libstdc++.so.6
 #4  0x000055555556ac6f in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::front (this=0x7fffffffd790) at /usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/bits/basic_string.h:1315
 #5  std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::front (this=0x7fffffffd790) at /usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/bits/basic_string.h:1315
 #6  openpower::pels::src::FRUIdentity::setPartNumber (this=this@entry=0x7fffffffd8a0, partNumber="") at ../extensions/openpower-pels/fru_identity.cpp:216
 #7  0x000055555556ae12 in openpower::pels::src::FRUIdentity::FRUIdentity (this=this@entry=0x7fffffffd8a0, partNumber="", ccin="", serialNumber="") at ../extensions/openpower-pels/fru_identity.cpp:102
 #8  0x0000555555562aaf in testHWCallout (pn="", ccin="", sn="", expectedPN="", expectedCCIN="", expectedSN="") at ../test/openpower-pels/fru_identity_test.cpp:97
 #9  0x00005555555645b0 in FRUIdentityTest_CreateHardwareCalloutTest_Test::TestBody (this=<optimized out>) at /usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/bits/basic_string.tcc:242
```

Fix this by avoiding accessing `front()` when the part number string
is empty.  While there, do a minor performance optimization to avoid
unnecessary string copies, by using `erase` instead of `substr`.

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I71cc195596def6ad0cd982e7294e2467beee987c
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants