WCHAR wszName;
In the debugger displays multiple "squares" and each addressed 0xcdcd
printf("Description: %ws\n", pIfRow->wszName); //prints nothing
Is there a reason it can not get the name from XP?
(All other info in MIB_IFTABLE is correct)
Thanks
0xcdcdcdcd indicates that wszName was never initialized. It is the default value of heap-allocated memory in the Debug build. Review the code that copies a string into wszName, it is not working. Presumably the call to GetIfTable() failed or you're iterating the table wrong.
Related
I use the code similar to that in Why UrlDownloadToFile::OnProgress always return ulProgress and ulProgressMax with the same value. I expect the ulProgress will be the number of bytes downloaded. However, when I try to download a large file(61,829,200 bytes), the last call to the callback function pass ulProgress as 61,812,069, not same as the final size. Does that mean the file is not downloaded completely? I try to check the downloaded file but find its size is 61,829,200 bytes, not 61,812,069bytes.
Why?
I have found the issue. When status code is BINDSTATUS_DOWNLOADINGDATA, the ulProgress will not reach the final size. There will be another status code BINDSTATUS_ENDDOWNLOADDATA, when that status code appears, then the ulProgress is the final size.
I working on a version bump on the cc65 and encountered a problem with the linuxdoc-tools. Since I can't fix the linuxdoc-tools and there is a simple workaround possible I decided to add an if statement to inform the user together with the workaround:
if {! [file exists ${prefix}/bin/perl] } {
ui_error "
«${prefix}/bin/perl» is missing but the linuxdoc-tools depends on it.
Please create an appropriate symbolic link for linuxdoc-tools to work.
"
exit 1
}
Crude but the best I can do since I'm neither the perl5 nor the linuxdoc-tools maintainer and I don't want to spend to much time on a version bump.
However, the MacPorts doesn't understand exit 1 and ui_error won't stop execution on its own.
How do I stop the execution so not to waste the users time on a build which will otherwise fail right at the end.
Use return -code error "error message", or the shorthand for the same thing, error "error message".
Note that you should use ui_error before that to print a human-readable message for the user – while the error message is also being printed, it can sometimes get lost in the output.
Additionally, note that $prefix/bin/perl is a build dependency of linuxdoc-tools. If it is also needed at runtime, you should submit a pull request that adds depends_run path:bin/perl:perl5 to the port rather than attempting to fix this bug in your port.
A practical example of the bug "in action" is the following:
Attacker sends: /hello-%08x.%08x.%08x.%08x
Server logs:
[17:17:28] Consoled: 'hello-082aeefc.00000131.0061b64c.00000011' run
from 192.168.0.3:32768
Update:
The bug is caused by the logging function NetManager_LogMessage which
takes the text to dump, adds a timestamp (using snprintf) and then
passes the whole string to the function File_printf without the needed
format argument (%s) and how to fix it?
What i have done wrong and why its happening?
I debug in IDA and when i test to Crash the Server. It returns the Memory Invalid access error.
my software is a Web Crawler,when I get the body from the http response, it cracks.
resp->body = Malloc(content_len);
memcpy(resp->body, body_start, content_len); //THIS IS THE FAULTY LINE
Malloc is a wrapper function of malloc,so resp->body is not NULL, and content_len is the length of memory area begin with body_start,but its content is "PK\003\004\024", "\003" is ETX(end of text), "\004" is EOT(end of transmission),"\024" is device control 4,I really don't know what 's the meaning of these strange chracters,why does it crack?
The body is ZIP encoded, from the ZIP wikipedia page;
Magic number
none, though PK\003\004, PK\005\006 (empty archive), or PK\007\008 (spanned archive) are common.
You'll need to check the header and unzip the body before reading it.
As for the segmentation fault, any of the 3 parameters to memcpy could be the culprit, code showing their initialisation is required to spot the exact problem. If you're using any of the string functions (strlen/strcpy) on the body in a non shown part of the code, they're likely to break with binary input like this.
Can someone please help me with interpreatation of this stack trace:
Loading modules: [ libumem.so.1 libc.so.1 libuutil.so.1 ld.so.1 ]
> $c
libc.so.1`strlen+0xc(80b37ba, fe679d2c, fe679d00, 0)
libc.so.1`snprintf+0x74(fe67d970, 1388, 80b37b8, efef9f68, 80b379d, fe679e30)
> 80b37ba::whatis
80b37ba is unknown
> fe679d2c::whatis
fe679d2c is unknown
> fe679d00::whatis
fe679d00 is unknown
strlen function gets one argument, but in this stack trace I see 3 addresses ? What is the meaning of them ?
regards
The debugger doesn't manage to interpret most of it.
The debugger may not know how many parameters a function gets. So it prints more. But you can ignore the extra parameters.
The parts that do make sense show that snprintf was called, and then call strlen. This is probably due to %s in the format string. The strlen parameter is similar (not identical, I don't know why), to snprintf's 3rd parameter.
So probably some code does something like snprintf("%d %s\n", number, string).
You can find the actual format string at fe67d970, and it will probably let you identify who called it (unless you use the same format string everywhere).