|
https://www.youtube.com/watch?v=Q16D8HRHDgQ
|
# ? Dec 8, 2015 15:56 |
|
|
# ? Jun 7, 2024 05:43 |
|
I'm making a type ID by taking the address of a function template static variable, reasoning that each instantiation of the template must give it a unique location. Seems to work fine. I'm curious if my reasoning is correct though, are there situations where this won't give the same pointer for a given type?C++ code:
|
# ? Dec 10, 2015 20:44 |
|
I don't have the standard handy, but I think it's safe. I know there are linker optimizations to fold identical constants to save space in the executable, which cause distinct static objects to have the same address, but it seems that in Visual C++, for one, you have to explicitly request it when you declare the variable Function pointers don't have the same guarantee IIRC, but again, I don't have the standard handy to check
|
# ? Dec 10, 2015 22:02 |
|
If you load a DLL I'm pretty sure they won't agree on type ids. Maybe that's not important though.
|
# ? Dec 10, 2015 22:06 |
|
hackbunny posted:Function pointers don't have the same guarantee IIRC, but again, I don't have the standard handy to check
|
# ? Dec 10, 2015 22:59 |
|
Sex Bumbo posted:If you load a DLL I'm pretty sure they won't agree on type ids. Maybe that's not important though. Oh, ick, you're right. You'd be forced to explicitly instantiate the template for classes exported by the DLL, and export the explicit instantiation as well. In fact I think this is exactly what Qt does
|
# ? Dec 11, 2015 01:10 |
|
Why aren't you using type_info?
|
# ? Dec 11, 2015 08:54 |
|
How does Microsoft distribute the VC++110/VS2012 headless build tools? Are they included in the Windows SDK or something? I'm trying to build a VS2012 project in CI (without VS2012 installed). There must be something installed on the build server because the 32-bit build works fine. But I can't build 64-bit because this directory is empty: C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\amd64
|
# ? Dec 13, 2015 04:59 |
|
Does C++ guarantee anything if a std::condition_variable is notified when there aren't any threads waiting on it? On recent OS X (libc++) and Linuxes (libstdc++), I've observed that, after the notify, the next thread to call wait on the condition variable will (nearly?) immediately be "woken up", but only if the overload of wait that takes a predicate is used (even if the predicate just returns true). Otherwise the waiting thread won't be woken up until the next time the condition variable is notified. I'm so confused. Here's my test case. Re-define DEADLOCK as 1 to use the overload without the predicate. The atomic bool in there is my attempt to ensure that notify_one is called in the main thread before the worker thread waits on the condition variable. C++ code:
|
# ? Dec 14, 2015 01:29 |
|
Sedro posted:How does Microsoft distribute the VC++110/VS2012 headless build tools? a
|
# ? Dec 14, 2015 01:39 |
|
Deus Rex posted:Does C++ guarantee anything if a std::condition_variable is notified when there aren't any threads waiting on it? On recent OS X (libc++) and Linuxes (libstdc++), I've observed that, after the notify, the next thread to call wait on the condition variable will (nearly?) immediately be "woken up", but only if the overload of wait that takes a predicate is used (even if the predicate just returns true). Otherwise the waiting thread won't be woken up until the next time the condition variable is notified. I'm so confused. The spec says that the predicated wait checks the predicate before trying to wait, so a predicate that always returns true is a pure no-op. Non-predicated wait is allowed to return whenever the hell it wants, independent of any calls to notify.
|
# ? Dec 14, 2015 01:48 |
|
Plorkyeran posted:They don't. You have to pull them out of an install of Visual Studio. Older versions were part of the Windows SDK, and 2015 is available standalone. Edit: technical preview, huh? they weren't kidding Sedro fucked around with this message at 21:34 on Dec 14, 2015 |
# ? Dec 14, 2015 17:29 |
|
pre:Program terminated with signal SIGSEGV, Segmentation fault. #0 0x5580f106 in memcpy () from libc.so.6 (gdb) bt #0 0x5580f106 in memcpy () from libc.so.6 #1 0x56437008 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?)
|
# ? Dec 16, 2015 13:54 |
|
netcat posted:
Are you aware of valgrind?
|
# ? Dec 16, 2015 15:31 |
|
netcat posted:Backtrace stopped: previous frame inner to this frame (corrupt stack?)
|
# ? Dec 16, 2015 16:19 |
|
feedmegin posted:Are you aware of valgrind? Yes ExcessBLarg! posted:Are you memcpying over the call stack? Potential uninitialized dest pointer? Unclear. This happens during shutdown where we don't do much copying as far as I know... We had a very similar issue a few months ago that seemed to be due to some static objects being destroyed in the wrong order, at least the issue disappeared when I fixed that but here it is again. Gonna have to dig into some valgrind logs I think but I can't really see anything. Also this is a multithreaded system so anything could be going on
|
# ? Dec 16, 2015 16:35 |
|
netcat posted:Yes Try rr.
|
# ? Dec 16, 2015 18:39 |
|
Also try AddressSanitizer.
|
# ? Dec 16, 2015 19:54 |
|
I'll have to check these out tomorrow. But it's a pretty classic heisenbug that doesn't appear when I actually try to find it
|
# ? Dec 16, 2015 20:15 |
|
Valgrind and asan are both handy for those because they tend to help isolate the cause of the bug rather than the symptoms.
|
# ? Dec 16, 2015 20:20 |
|
Ralith posted:Valgrind and asan are both handy for those because they tend to help isolate the cause of the bug rather than the symptoms. Yeah, sure. The problem is that it's a good chance it boils down to some threading issue and running with valgrind and so on changes the timing of things so whatever's causing the crash might never occur.
|
# ? Dec 16, 2015 20:43 |
|
Helgrind and ThreadSanitizer are both great for detecting race conditions even without you hitting the cases that actually cause problems.
|
# ? Dec 16, 2015 21:17 |
|
Many platforms will run destructors for global objects even if there are still threads in flight (if, say, one thread calls exit). Solution: find a way to remove the global destructors, or shut down all your threads before exiting.
|
# ? Dec 17, 2015 00:38 |
|
rjmccall posted:Many platforms will run destructors for global objects even if there are still threads in flight (if, say, one thread calls exit). Solution: find a way to remove the global destructors, or shut down all your threads before exiting. -Wexit-time-destructors helps with the first once, and there's also quick_exit/_Exit if you want to just blow everything up without calling destructors.
|
# ? Dec 17, 2015 00:45 |
|
This is really well times part of the thread. Asan is exploding on a bad read from a dlopen in an android app. So some static being initialized somewhere in the 30 meg library is misbehaving. What are our options to track it down? I'm thinking of we could dump the .init of the elf we could get the order of init and add some logging to bisect it. But not sure if that's possible or if there's a better way.
|
# ? Dec 17, 2015 03:53 |
|
So for a more embarrassing question. To use Asan we have to move to gcc 4.8.1 (from ancient 4.6.3) and suddenly this code fails to compile:code:
e: It seems it's because the shared_ptr is in fact a tr1 shared_ptr (the library we're using still uses tr1 stuff). eh... netcat fucked around with this message at 12:23 on Dec 17, 2015 |
# ? Dec 17, 2015 10:53 |
|
netcat posted:So for a more embarrassing question. To use Asan we have to move to gcc 4.8.1 (from ancient 4.6.3) and suddenly this code fails to compile: To make a hollow sound laughing. One of our build platforms is still on gcc 3.4 and that's not even the oldest version in the building.
|
# ? Dec 17, 2015 11:21 |
|
netcat posted:
Someone needs an R-type sticker stapled to their forehead for this.
|
# ? Dec 17, 2015 14:43 |
|
Hughlander posted:This is really well times part of the thread. Asan is exploding on a bad read from a dlopen in an android app. So some static being initialized somewhere in the 30 meg library is misbehaving. What are our options to track it down? I'm thinking of we could dump the .init of the elf we could get the order of init and add some logging to bisect it. But not sure if that's possible or if there's a better way.
|
# ? Dec 18, 2015 08:59 |
|
Ralith posted:By "asan is exploding" do you mean it's detecting an error or is itself malfunctioning? If the former, it should usually give you a detailed backtrace (which, if you're using old tools or are in a weird environment, may need symbolization). Sorry that was poorly written. It is finding a read overflow but gives no traceback just the PC and some registers. Running the PC through the sym file generated for brake pad doesn't show it as in our code at all. If we could generate a full traceback for it on Android I'd be ecstatic.
|
# ? Dec 18, 2015 14:40 |
|
Hughlander posted:Sorry that was poorly written. It is finding a read overflow but gives no traceback just the PC and some registers. Running the PC through the sym file generated for brake pad doesn't show it as in our code at all.
|
# ? Dec 18, 2015 21:21 |
|
Hughlander posted:Sorry that was poorly written. It is finding a read overflow but gives no traceback just the PC and some registers. Running the PC through the sym file generated for brake pad doesn't show it as in our code at all. As someone who's been there, I have nothing to offer but my sympathies.
|
# ? Dec 19, 2015 17:30 |
|
I'm getting a memory leak but I'm unsure what's causing it. I've set up a linked list class: code:
code:
code:
code:
code:
code:
|
# ? Jan 5, 2016 23:14 |
|
You can't just malloc a chunk of memory and then expect objects like vectors of strings to exist in it. You have to use the new operator instead of malloc to make a row_node so that the vectors get constructed properly. Then on the other end, you use delete instead of free and the vectors' destructors will run too and release the memory they're using.
|
# ? Jan 5, 2016 23:25 |
|
Vanadium posted:You can't just malloc a chunk of memory and then expect objects like vectors of strings to exist in it. You have to use the new operator instead of malloc to make a row_node so that the vectors get constructed properly. I'll try that out, although they appear to be working fine as is (that is, all vector operations I've tried work just fine) JawKnee fucked around with this message at 23:34 on Jan 5, 2016 |
# ? Jan 5, 2016 23:27 |
|
JawKnee posted:I'll try that out, although they appear to be working fine as is (that his, all vector operations I've tried work just fine) uninitialized memory is a magic thing
|
# ? Jan 5, 2016 23:30 |
|
Vanadium posted:You can't just malloc a chunk of memory and then expect objects like vectors of strings to exist in it. You have to use the new operator instead of malloc to make a row_node so that the vectors get constructed properly. Thanks, changing from malloc/free to new/delete has cleared up the memory leak issue Hubis posted:uninitialized memory is a magic thing so I see
|
# ? Jan 5, 2016 23:33 |
|
Vanadium posted:You can't just malloc a chunk of memory and then expect objects like vectors of strings to exist in it. You have to use the new operator instead of malloc to make a row_node so that the vectors get constructed properly. You can use malloc and free with classes too. Just use placement new on the allocated pointer to run the constructor and call the destructor manually with obj->~MyObject() before freeing it.
|
# ? Jan 6, 2016 00:59 |
|
I have a question, if I have an array of a base class such as vector<MyBaseClass> of which each element is made up of a pointer to a derived class such that each element is a different derived class such as: MyFirstDerivedClass, MySecondDerivedClass, MyThirdDerivedClass, ...., etc. Will dynamic_cast back to their original type preserve their data? I'm unsure if upcasting and then downcasting will allow me to keep it's data preserved (that are specific to the derived class's data member fields). e & example: code:
Raenir Salazar fucked around with this message at 01:37 on Jan 6, 2016 |
# ? Jan 6, 2016 01:26 |
|
|
# ? Jun 7, 2024 05:43 |
|
If it's a vector of pointers (std::vector<MyBaseClass*>), yes. The original object is still there, and the vector just happens to hold a pointer to the part of it that represents the base class. If it's a vector of objects (std::vector<MyBaseClass>), no. The vector holds a copy of the base-class portion of the object; the original object is still around somewhere, but it's completely different from the object in the vector, which is dynamically just an object of the base type.
|
# ? Jan 6, 2016 02:20 |