-
Notifications
You must be signed in to change notification settings - Fork 111
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
Crash while building #460
Comments
Was this on a fresh clone/pull of the repo? It's definitely related to #450, I'll look more closely later to see which place it is coming from this time if this is indeed something still present after my did PR. If it is another spot, I may make a branch and apply the same fix at the other similar malloc calls in that class and ask that you try to compile it on your machine. |
Can you try building this branch? |
Hi, it was indeed a fresh clone from the repo.
|
I'll push another thing for you to try tomorrow. What is your system and compiler by the way? GCC? |
I'm running Ubuntu 22
|
This is very weird, I feel like this may be due to interaction between signed and unsigned integers. I tried using GCC 8.4.1 and GCC 13.1.0 (a bit more complicated for other versions) and cannot reproduce this error. I forgot why I use signed integer for VecDH. This should probably be fixed as well. |
I wonder if this helps: https://github.com/pca006132/manifold/tree/size_t If not, I will need to compile GCC 8.4.0 and have a look... |
Here is a more direct fix https://github.com/geoffder/manifold/tree/vec-dh-noinline (adding gcc's |
Maybe we should just pass a |
OK I found the following issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544 @geoffder That allocation bug should be fixed for GCC 13.1, so it is weird that you triggered it in #450. At least for the example program in 87544, it did not trigger with GCC 13.1 and trunk, I cannot find the release info for 13.1.1 so this is pretty weird... |
🤔 it is definitely weird, as that is the version that I'm compiling with. Anyway, I'm sure that there are others out there that will be using gcc versions suffering from this for quite some time, so it may be a good idea to rule out the error with the |
@geoffder wondering if your compiler will reproduce the bug in 87544: #include <complex>
#include <iostream>
#include <limits>
#include <vector>
template<class T>
class my_allocator : public std::allocator<T>
{
public:
typedef std::size_t size_type;
typedef std::ptrdiff_t difference_type;
typedef T* pointer;
typedef const T* const_pointer;
typedef T& reference;
typedef const T& const_reference;
typedef T value_type;
template<class U>
struct rebind { typedef my_allocator<U> other; };
my_allocator() : std::allocator<T>() {}
my_allocator(const my_allocator& other) : std::allocator<T>(other) {}
template<class U>
my_allocator(const my_allocator<U>& other) : std::allocator<T>(other) {}
~my_allocator() {}
pointer allocate(size_type num, const void* hint = 0)
{
std::size_t size = num * sizeof(T);
void *result = std::malloc(size);
if(size>16 && (std::size_t(result) & 15)!=0) {
std::free(result);
return 0;
}
return static_cast<pointer>( result );
}
void deallocate(pointer p, size_type /*num*/) { std::free(p); }
};
typedef std::complex<float> cplx;
int main() {
std::vector<cplx, my_allocator<cplx> > v;
v.push_back(cplx());
return 0;
} and I will open a PR to fix size_t inconsistency and disable the alloc size larger than warning. |
While building on my computer I get the following error:
Any idea what might cause this?
The text was updated successfully, but these errors were encountered: