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

Support for instantiating model from preloaded data #9

Closed
liob opened this issue Aug 11, 2019 · 5 comments
Closed

Support for instantiating model from preloaded data #9

liob opened this issue Aug 11, 2019 · 5 comments

Comments

@liob
Copy link

liob commented Aug 11, 2019

Thank you for creating this awesome wrapper!

Please support model instantiation from already loaded data. In this specific case, I have an unsigned char array with a known length (unsigned int) which holds the data. I have hacked together an appropriate function by basically copying your code for loading the protobuffer for the most part. However, as I am quite new to c++, the code is quite ugly. I think this is not an uncommon case, and the wrapper would be even more useful by supporting it.

Kind regards, and best wishes.

@ksasso1028
Copy link

you should be able to feed your array to your input layer?

@serizba
Copy link
Owner

serizba commented Jun 12, 2020

Hi @liob

Sorry for answer so late. I do not now what do you mean with 'instantiation from already loaded data'. Could you please explain a bit more what do you mean?

Thanks!

@liob
Copy link
Author

liob commented Jun 12, 2020

@ksasso1028 sorry for the late response. I did not recognize, that you answered to this issue.

@serizba I am not a c++ developer, sorry for not being clear about the issue. My suggestion is to add the ability to instantiate the model not from a (protobuffer) file but to allow instantiation from memory. The use case is, that you can ship a single binary (exe file) which already contains the model. As mentioned before, in my case I have the model data as unsigned char array with a known length.

To be perfectly clear, this is not about feeding data to the model, but to instantiate the model itself from some kind of in memory construct.

@serizba
Copy link
Owner

serizba commented Jun 13, 2020

So, if I understood correctly, you have the protobuffer loaded in memory as char array. If that is the case I guess you could take a look to the read function in Model.cpp. In that function the .pb file is read into a char array and then the array is used to create a new Buffer.

You could adapt that function to skip reading the file into an array as you already have the array.

I hope it helps you.

@liob
Copy link
Author

liob commented Jun 18, 2020

@serizba I managed to hack together a version that can do this. This works fine for me. I just thought, this might be of interest to others. I am closing the issue.

@liob liob closed this as completed Jun 18, 2020
abertoldi added a commit to kirasystems/cppflow that referenced this issue Jun 18, 2021
The ASan report is as follows:

AddressSanitizer:DEADLYSIGNAL
=================================================================
==74==ERROR: AddressSanitizer: SEGV on unknown address 0x6030bf3b722e (pc 0x7fc277c6ae10 bp 0x7ffe22b2c9a0 sp 0x7ffe22b2c158 T0)
==74==The signal is caused by a READ memory access.
    #0 0x7fc277c6ae10  /build/glibc-eX1tMB/glibc-2.31/string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:365
    #1 0x49d947 in __asan_memcpy (/home/docker/kiravision/test/clang-memtest+0x49d947)
    serizba#2 0x50e00a in TF_TString_ResizeUninitialized(TF_TString*, unsigned long) /opt/tensorflow/include/tensorflow/core/platform/ctstring_internal.h:278:7
    serizba#3 0x50ba34 in TF_TString_Copy(TF_TString*, char const*, unsigned long) /opt/tensorflow/include/tensorflow/core/platform/ctstring_internal.h:389:17
    serizba#4 0x50bbac in Model::restore(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /home/docker/kiravision/cppflow/src/Model.cpp:107:5
    serizba#5 0x4e98e2 in KiraVision::LearnedModel::LearnedModel(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /home/docker/kiravision/src/LearnedModel.cpp:12:13
    serizba#6 0x4e28ed in KiraVision::TableDetector::TableDetector(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, KiraVision::LogLevel const&) /home/docker/kiravision/src/TableDetector.cpp:13:24
    serizba#7 0x4d058a in main /home/docker/kiravision/test/memtest.cpp:16:31
    serizba#8 0x7fc277bd30b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
    serizba#9 0x425ccd in _start (/home/docker/kiravision/test/clang-memtest+0x425ccd)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /build/glibc-eX1tMB/glibc-2.31/string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:365
==74==ABORTING

The problem was incorrect initalization of a `TF_TString`. The existing
code initialized it as `new TF_Tstring` (which is not really any kind of
initalization, just memory allocation). `TF_TString`'s have to be
initialized with `TF_TString_Initialize` before they an be used. The
fact that the offending code is using a `unique_ptr` to ensure deletion
of the `TF_TString` makes it all a little clunky.
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

3 participants