|
Ripping my hair out with this one. I develop for some Windows Embedded Compact 7 products where we use VS2008 with add-on SDKs. All service packs applied, I've been using the same setup for the A week or so ago, I did a code merge between two branches and broke on of my applications. In trying to debug the issue, I discovered that no matter where I placed breakpoints, they would immediately go clear with a warning. Mousing over shows the message in the title bar. In doing my debug of the debugger work, I have:
- full clean rebuild;
- delete all PDB, suo and ncb files;
- create a new application;
Nothing corrects the issue. In fact, the last item is a simple dummy hello world dialog app, and it has the same breakpoint issue. So something bad has happened to the installation I'm guessing. In reading all the SO discussions, it appears that most people solve this by making random changes until it starts working.
Does anyone have a definitive explanation or solution for this behavior?
Thanks
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
Seems I fixed this by doing a repair installation on VS2008. Should have thought of that last week.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
The bigger question is why you are still using VS2008 given all the upgrades above you are free 
WIN CE was supported until at least VS2015 from memory.
Update: Ignore that you are trying to debug you have to be on VS2008 my bad
In vino veritas
modified 8-Dec-19 19:27pm.
|
|
|
|
|
In principle, you can choose a toolset from an earlier VS installation in any version of VS. If VS 2008 and a newer version are installed, you should be able to select the VS 2008 toolset in the newer VS for the purpose of debugging, or even building executables. Maybe intellisense won't like it, but you can disable intellisense if it gets too annoying.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Pretty sure you have to have a stub running in Win CE target to debug and if I remember correctly it is tied to the VS version. You can definitely compile without issue but I recall issues with debugging.
In vino veritas
|
|
|
|
|
Good point. I've never tried this with different target platform applications.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Good question, but it's the nature of embedded systems. My customers are still using systems they purchased in 2006. We're still supporting CE 5.0 and WEC7. Microsoft sort of lost their way after WEC7, and the tools stopped supporting the embedded arena. Microsoft was ripped a new bloody one with this decision, and eventually added support back into the Visual Studio, but the support does not extend back to 5.0 and 7.0. My team dug into this pretty deeply a few years back when we had to deal with this. Do you have knowledge of this changing?
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
Well, I spoke to soon  . The re-installation did not fix this completely. My breakpoints are back, but any attempts at compiling is a disaster.
There was an issue from long ago (I even have notes back from 2017 on this) about issues with the default include order. My notes cover about 95% of what needs to be done to correct it, but I think I missed one important key. Sigh.
I'm backing up to a scrubbed system and re-installing everything. VMs are nice.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
I'm going to close this out for posterity's sake.
Part of the problem with having to use VS2008 is that people who make extensions don't test against very old versions, and let's face it, 2008 is a gnarly old thing (but it's better than EVC++). Anyway, a long about December of last year I was trying to track down an issue with stack allocation. One tool I tried to use is Intel's VTune. Once installed, my woes began. I scrubbed everything to recover. Not only did it hose the breakpoints, but things would not compile, etc. I'm a busy guy, and I hate not being able to go back and do a true cause analysis.
New post coming up 
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
I could use some very basic assistance solving this problem.
The struct is located inside class function and I am not sure if that is OK.
I am trying to port C code to C++.
Here is the error
I get same error for both test calls to malloc
../src/MODULES/M_BLUEZ/CBLUEZ.cpp:505:14: error: invalid conversion from ‘void*’ to ‘hci_dev_list_req*’ [-fpermissive]
dl = malloc(HCI_MAX_DEV * sizeof(*dr) + sizeof(*dl));
Here is the offending code snippet
<pre> struct hci_dev_list_req *dl;
struct hci_dev_req *dr;
int dev_id = -1;
int i, sk, err = 0;
dl = malloc(HCI_MAX_DEV * sizeof(*dr) + sizeof(*dl));
if (!dl) {
err = errno;
goto done;
}
dl = malloc(HCI_MAX_DEV * sizeof(struct hci_dev_req) + sizeof(uint16_t));
Thanks
Cheers
|
|
|
|
|
Since malloc can only return a void*, it must be cast to the receiving type:
dl = reinterpret_cast<hci_dev_list_req>(malloc(HCI_MAX_DEV * sizeof(*dr) + sizeof(*dl)));
|
|
|
|
|
Thanks,
just figured that out.
Appreciate your reply anyway.
Is it more appropriate to do
reinterpret_cast<hci_dev_list_req> or just
(hci_dev_list_req*) ?
|
|
|
|
|
Since you are "porting C code to C++", why don't you replace malloc/free with the new/delete?
Just use C++ allocation operators/methods and you won't need every time cast the returned pointer to the correct type.
|
|
|
|
|
I was going to suggest the use of new, but since he is allocating a single area for two separate structures it would be more complicated.
|
|
|
|
|
I don't think it's two structs, it looks like it's N structs plus a 16 bit number, which maybe could contain the size. If so, it should be converted to a std::vector.
On a side note, sizeof(uint16_t) deserves a place in the coding horror forum 
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
You are correct. However, given many of OP's previous questions I think it is a bit too soon to introduce him to the new operator.
|
|
|
|
|
In C++ it is more appropriate to use reinterpret_cast.
|
|
|
|
|
Please consider rewriting it in proper C++.
I don't blame the usage of goto in C code, but C++ provides better alternatives.
|
|
|
|
|
It's not proper C code to start with, and I'm not even complaining about goto. Given the weird malloc statements it's pretty obvious there's some severe memory clusterfuck taking place. The structs and pointers being defined do not represent what is being stored. dl is being allocated twice, and dr not at all.
Given the the quality of the visible code, I strongly doubt that the code that uses these pointers is accessing the underlying memory correctly.
There's not a chance in hell to turn that into clean C++ if the original C code isn't cleaned up first.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
While I agree on your observations, I don't completely agree on your last sentence. If you are able to capture the actual requirements, you don't need to clean-up the original C, in order to produce neat C++ one.
|
|
|
|
|
This code looks very, very wrong. It shouldn't be possible to convert this into clean C++ code, because it's not clean C code to start with!
First of all, you have two pointers that require some allocation, but you have two allocations assigned to the same variable, dl. Why do you have two allocations for dl? Where is the allocation for dr?
Second, both dl and dr are declared as pointers to some kind of struct. In clean C code, the implicit meaning of this is that these pointers are pointing to one or more structs of their respective types.
Apparently, you are allocating data structures that contain arrays of data structures along with additional information, without ever declaring that memory structure as data structure. That is completely inaccaptable, unclean code.
You should start by defining your actual data structures in C and clean up your original code. Then you can define arrays as std::vector or std::array, to safe yourself the effort of managing containers, and use new/delete to allocate your actual structs if you do need to allocate them dynamically - chances are, that once you get the container memory auto-managed by C++ classes, you can simply declare those structs on the stack.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
First, I apologize that I erroneously posted TWO malloc calls.
It woudl have helped if I did not, since it generated unnecessary responses.
I was asking for help on malloc , not on whole snippet.
My apology.
I have "inherited" / using the original C code and have no control over how clean or stupid it is.
Since the original code is "very well documented" my intent is to get rid of the current "library" so I can figure out what the code does step by step.
So far I have part of hciconfig working thanks to the group help with the malloc issue.
Now I have small issue with "invalid pointer" which should go away after I clean up the "struct" assignments.
The "invalid pointer" is reported when the code is actually running, which by itself is "new" one on me. I may ask for help on that one, if I get stuck.
I got no issues learning to use "new" or any other C++ specific features.
Any comments on the contrary are not appreciated.
Cheers
|
|
|
|
|
Thanks for responding. It's good to know a little more context.
As for the "invalid pointer" error, I disagree with the notion of either using a simple C-style type cast, or reinterpret_cast. Both are only workarounds to a severe problem in your code. You're only telling your compiler to shut up, but that doesn't solve the problem that is causing this! All you'd achieve is that the program compiles - and then crashes at run-time!
To properly implement this in C++, the first step is to analyze how that pointer is being used, and what data fields are supposed to be accessed via this pointer. There are two possibilities:
1. all fields being accessed are data members of struct hci_dev_list_req . If this is the case, the malloc() statement from the original code is garbage (both of them). In C++, you should declare dl as follows:
std::array<hci_dev_list, HCI_MAX_DEV> dl;
There's no need for type casts, and no need for allocation or cleaning up - std::array takes care of that.
2. Some fields being accessed are not members of struct hci_dev_list_req . In this case the declaration of dl is garbage! dl is not a pointer to some struct or array of structs. Instead it's a pointer to some undefined struct which, among other things, contains hci_dev_list_req elements. And that is exactly how it should be declared. So, if the original C program does not provide the appropriate struct definition, you should create one yourself.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Bad news.
I tried this
array<hci_dev_list_req, HCI_MAX_DEV> dl_array;
and it broke GPIO class after enabling C11 in crosscompiler - as requested by complier error.
I guess I need to go back, at least temporary, and just hack it with
reinterpret_cast. .
Just FYI - the struct are used to access ioctl and that is an area I do no want to mess with since it works for other I/O access.
struct hci_dev_req {
uint16_t dev_id;
uint32_t dev_opt;
};
struct hci_dev_list_req {
uint16_t dev_num;
struct hci_dev_req dev_req[0];
};
I have not given it much thought, but could I put the "malloc" replacement as "class variable" ( instead allocating / freeing the memory in function itself as it was done in C ) or into a class constructor ?
|
|
|
|
|
I'm not sure I understand. If the variables you called dl and dr are part of your code, then surely it is in your hands how to define and use them? If any code breaks, it is an indication that code was bad to start with. I'm not surprised though: there must have been a reason for the odd malloc statements, and my suspicion, as stated before, is that someone uses these pointers not as pointer to some struct array, but as a pointer to some meta-struct: see my other posting with a suggestion how to declare such a struct.
If you don't fix that broken code, it won't be clean. And reinterpret_cast does not fix anything. It only makes your code compile, but it doesn't make it work, much less clean.
I do not suggest to fix or change the structs hci_dev_req and hci_dev_list_req themselves, only the code using them. That code defines variables called dl and dr, and the way these are allocated currently indicates that code is broken and needs to be fixed. And that includes any code that uses dl and dr.
If for some reason you can't get std::array to work even though it does not require C++11, you could try std::vector instead: the main difference is that std::vector does not require the size to be known at compile time, and it can be resized dynamically. If HCI_MAX_DEV is a constant, std::array should work just fine; otherwise you need std::vector.
Of course, you can't pass a std::array into ioctl where it requires a hci_dev_list_req - you first need to convert it. That is not unusual for modern C++ code using old C APIs: in such cases you need some helper or wrapper functions that perform these conversions under the hood.
If you want to avoid these conversions, then the task you're asking for is an entirely different one - you should have stated that much from the beginning. Then we could have told you that it's not a good idea to transport a hackish C struct into C++ code and expect the resulting code to be 'clean'.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
