Search Results

Search found 7 results on 1 pages for 'themoondothshine'.

Page 1/1 | 1 

• Linux, GNU GCC, ld, version scripts and the ELF binary format -- How does it work? [closed]

  - by themoondothshine

  I'm trying to learn more about library versioning in Linux and how to put it all to work. Here's the context: I have two versions of a dynamic library which expose the same set of interfaces, say libsome1.so and libsome2.so. An application is linked against libsome1.so. This application uses libdl.so to dynamically load another module, say libmagic.so. Now libmagic.so is linked against libsome2.so. Obviously, without using linker scripts to hide symbols in libmagic.so, at run-time all calls to interfaces in libsome2.so are resolved to libsome1.so. This can be confirmed by checking the value returned by libVersion() against the value of the macro LIB_VERSION. So I try next to compile and link libmagic.so with a linker script which hides all symbols except 3 which are defined in libmagic.so and are exported by it. This works... Or at least libVersion() and LIB_VERSION values match (and it reports version 2 not 1). However, when some data structures are serialized to disk, I noticed some corruption. In the application's directory if I delete libsome1.so and create a soft link in its place to point to libsome2.so, everything works as expected and the same corruption does not happen. I can't help but think that this may be caused due to some conflict in the run-time linker's resolution of symbols. I've tried many things, like trying to link libsome2.so so that all symbols are alised to symbol@@VER_2 (which I am still confused about because the command nm -CD libsome2.so still lists symbols as symbol and not symbol@@VER_2), but nothing seems to work. What am I doing wrong?

  Read the article

• Linux core dumps are too large!

  - by themoondothshine

  Hey guys, Recently I've been noticing an increase in the size of the core dumps generated by my application. Initially, they were just around 5MB in size and contained around 5 stack frames, and now I have core dumps of 2GBs and the information contained within them are no different from the smaller dumps. Is there any way I can control the size of core dumps generated? Shouldn't they be at least smaller than the application binary itself? Binaries are compiled in this way: Compiled in release mode with debug symbols (ie, -g compiler option in GCC). Debug symbols are copied onto a separate file and stripped from the binary. A GNU debug symbols link is added to the binary. At the beginning of the application, there's a call to setrlimit which sets the core limit to infinity -- Is this the problem?

  Read the article

• Strange behavior of std::cout &operator<<...

  - by themoondothshine

  Hey ppl, I came across something weird today, and I was wondering if any of you here could explain what's happening... Here's a sample: #include <iostream> #include <cassert> using namespace std; #define REQUIRE_STRING(s) assert(s != 0) #define REQUIRE_STRING_LEN(s, n) assert(s != 0 || n == 0) class String { public: String(const char *str, size_t len) : __data(__construct(str, len)), __len(len) {} ~String() { __destroy(__data); } const char *toString() const { return const_cast<const char *>(__data); } String &toUpper() { REQUIRE_STRING_LEN(__data, __len); char *it = __data; while(it < __data + __len) { if(*it >= 'a' && *it <= 'z') *it -= 32; ++it; } return *this; } String &toLower() { REQUIRE_STRING_LEN(__data, __len); char *it = __data; while(it < __data + __len) { if(*it >= 'A' && *it <= 'Z') *it += 32; ++it; } return *this; } private: char *__data; size_t __len; protected: static char *__construct(const char *str, size_t len) { REQUIRE_STRING_LEN(str, len); char *data = new char[len]; std::copy(str, str + len, data); return data; } static void __destroy(char *data) { REQUIRE_STRING(data); delete[] data; } }; int main() { String s("Hello world!", __builtin_strlen("Hello world!")); cout << s.toLower().toString() << endl; cout << s.toUpper().toString() << endl; cout << s.toLower().toString() << endl << s.toUpper().toString() << endl; return 0; } Now, I had expected the output to be: hello world! HELLO WORLD! hello world! HELLO WORLD! but instead I got this: hello world! HELLO WORLD! hello world! hello world! I can't really understand why the second toUpper didn't have any effect.

  Read the article

• Linux, GNU GCC, ld, version scripts and the ELF binary format -- How does it work??

  - by themoondothshine

  Hey all, I'm trying to learn more about library versioning in Linux and how to put it all to work. Here's the context: -- I have two versions of a dynamic library which expose the same set of interfaces, say libsome1.so and libsome2.so. -- An application is linked against libsome1.so. -- This application uses libdl.so to dynamically load another module, say libmagic.so. -- Now libmagic.so is linked against libsome2.so. Obviously, without using linker scripts to hide symbols in libmagic.so, at run-time all calls to interfaces in libsome2.so are resolved to libsome1.so. This can be confirmed by checking the value returned by libVersion() against the value of the macro LIB_VERSION. -- So I try next to compile and link libmagic.so with a linker script which hides all symbols except 3 which are defined in libmagic.so and are exported by it. This works... Or at least libVersion() and LIB_VERSION values match (and it reports version 2 not 1). -- However, when some data structures are serialized to disk, I noticed some corruption. In the application's directory if I delete libsome1.so and create a soft link in its place to point to libsome2.so, everything works as expected and the same corruption does not happen. I can't help but think that this may be caused due to some conflict in the run-time linker's resolution of symbols. I've tried many things, like trying to link libsome2.so so that all symbols are alised to symbol@@VER_2 (which I am still confused about because the command nm -CD libsome2.so still lists symbols as symbol and not symbol@@VER_2)... Nothing seems to work!!! Help!!!!!! Edit: I should have mentioned it earlier, but the app in question is Firefox, and libsome1.so is libsqlite3.so shipped with it. I don't quite have the option of recompiling them. Also, using version scripts to hide symbols seems to be the only solution right now. So what really happens when symbols are hidden? Do they become 'local' to the SO? Does rtld have no knowledge of their existence? What happens when an exported function refers to a hidden symbol?

  Read the article

• Referencing invalid memory locations with C++ Iterators

  - by themoondothshine

  I am a big fan of GCC, but recently I noticed a vague anomaly. Using __gnu_cxx::__normal_iterator (ie, the most common iterator type used in libstdc++, the C++ STL) it is possible to refer to an arbitrary memory location and even change its value without causing an exception! Is this expected behavior? If so, isn't a security loophole? Here's an example: #include <iostream> using namespace std; int main() { basic_string<char> str("Hello world!"); basic_string<char>::iterator iter = str.end(); iter += str.capacity() + 99999; *iter = 'x'; cout << "Value: " << *iter << endl; }

  Read the article

• Maximum length of a std::basic_string<_CharT> string

  - by themoondothshine

  Hey all, I was wondering how one can fix an upper limit for the length of a string (in C++) for a given platform. I scrutinized a lot of libraries, and most of them define it arbitrarily. The GNU C++ STL (the one with experimental C++0x features) has quite a definition: size_t npos = size_t(-1); /*!< The maximum value that can be stored in a variable of type size_t */ size_t _S_max_len = ((npos - sizeof(_Rep_base))/sizeof(_CharT) - 1) / 4; /*!< Where _CharT is a template parameter; _Rep_base is a structure which encapsulates the allocated memory */ Here's how I understand the formula: The size_t type must hold the count of units allocated to the string (where each unit is of type _CharT) Theoretically, the maximum value that a variable of type size_t can take on is the total number of units of 1 byte (ie, of type char) that may be allocated The previous value minus the overhead required to keep track of the allocated memory (_Rep_base) is therefore the maximum number of units in a string. Divide this value by sizeof(_CharT) as _CharT may require more than a byte Subtract 1 from the previous value to account for a terminating character Finally, that leave the division by 4. I have absolutely no idea why! I looked at a lot of places for an explanation, but couldn't find a satisfactory one anywhere (that's why I've been trying to make up something for it! Please correct me if I'm wrong!!).

  Read the article

• C++ Template Classes and Copy Construction

  - by themoondothshine

  Is there any way I can construct an new object from the given object if the template parameters of both objects are identical at run-time? For example: I have a template class with the declaration: template<typename _Type1, typename _Type2> class Object; Next, I have two instantiations of the template: template class Object<char, int>; template class Object<wchar_t, wint_t>; Now, I want to write a member function such as: template<typename _Type1, typename _Type2> Object<char, int> Object<_Type1, _Type2>::toCharObject() { if(__gnu_cxx::__are_same<_Type1, char>::__value) return *this; else { //Perform some kind of conversion and return an Object<char, int> } } I have tried a couple of techniques, such as using __gnu_cxx::__enable_if<__gnu_cxx::__are_same<_Type1, char>::__value, _Type1>::__type in a copy constructor for the Oject class, but I keep running into the error: error: conversion from ‘Object<wchar_t, wint_t>’ to non-scalar type ‘Object<char, int>’ requested Is there no way I can do this? Any help will be greatly appreciated!

  Read the article

1