I have the following gdb script:
define test1
printf " Foo "
!date
printf "\n"
end
I expected the output to be:
Foo Tue Oct 1 15:01:58 PDT 2013
However, what I am getting is:
Tue Oct 1 15:01:58 PDT 2013
Foo
I feel I need to somehow "flush" the print. Can someone please help me understand what is going on here. Why is the output reversed.
Thank you,
Ahmed.
It looks like a gdb bug to me. I agree that printf ought to flush its output stream. Could you please file this in gdb bugzilla?
Related
I'm trying to program in C on Eclipse, I have installed and configured MinGW, but I have a problem that I don't understand:
I have some simple code:
#include <stdio.h>
#include <stdlib.h>
int main(void) {
int num1,num2;
setbuf(stdout,NULL);
printf("enter two numbers");
scanf("%d%d",&num1,&num2);
if(num1>num2){
printf("num1 is greater than num2");
}else{
printf("num2 is greater than num1);
}
return 0;
}
After I compile and run, it shows me "Enter two numbers" and I enter two numbers, I can't see any further output and keyboard function doesn't work on console screen, it doesn't give me an error, but it does show some strange output on console:
<terminated>
<terminated>(exit value: -1.073.741.515) CPS:exe
You're not reading in the values correctly:
scanf("%d%d",num1,num2);
The %d format specifier for scanf expect a int *, i.e. a pointer to an int, as an argument. It needs the address of a variable to be able to write a value to where that address is stored.
You're instead passing the current values of num1 and num2 which are essentially garbage values because the variables have not been written to.
You instead want:
scanf("%d%d",&num1,&num2);
I don't kwon if the code you post is exactly the same as what you compiled, when I copy and compile the code you posted, gcc report an error at line:
printf("num2 is greater than num1);
There lost the ending quotation mark in printf();
After I fixed this error, it works well. My environment is
Linux DESKTOP-7VH0PN1 5.4.72-microsoft-standard-WSL2 #1 SMP Wed Oct 28 23:40:43 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
With gcc:
gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
Copyright (C) 2019 Free Software Foundation, Inc.
My environment is Debian GNU/Linux 11.
The fprintf function with param stdout or stderr gives unexpected output order.
int main() {
std::cout << "Hello, World!" << std::endl;
fprintf(stderr, "22222\n");
fprintf(stdout, "111\n");
printf("3333 \n");
printf("44444 \n");
return 0;
}
I've run this many times and got many different results:
//①
22222
Hello, World!
111
3333
44444
//②
Hello, World!
111
3333
44444
22222
What's the reason?
Or, I want to understand the phenomenon, what knowledge do I need?
On my understanding, the output log should like this:
//③
Hello, World!
22222
111
3333
44444
About the two output logs of ①/②, I don't understand.
I think log ③ is right, but it does not appear, that makes me wonder.
The output is never like ② because output to stderr isn't buffered so 22222 will be flushed immediately and would be before any other numbers. Output to stdout may be line-buffered (default on Linux) or full-buffered (default on Windows)
The output shouldn't be like ① either because you're already flushing with std::endl in the first line, hence Hello, World! would be printed first. That's why never use std::endl unless you really know what it's doing. Always use std::cout << "Hello, World!\n";. See "std::endl" vs "\n"
③ should be the correct output because on Linux it'll flush on every statement, and on Windows the final 3 writes to stdout are flushed at once at the end
Hello, World!
22222
111
3333
44444
If there are any differences then there are some issues with your stdlib
By default the legacy and C++ streams are also synchronized so it's possible to mix both types of streams with some performance penalty. You can disable it like this
std::ios::sync_with_stdio(false);
to get better performance but now the Hello, World! string can be printed anywhere
What is the difference of the output between use getsizeof and st_size ?
When I use getsizeof the output is 144 but when I use st_size is 148. Anybody knows why this happening.
Any help will greatly appreciated.
From How to check file size in python?:
Note: the implementation of os.path.getsize is simply return os.stat(filename).st_size – wim Mar 21 '13 at 11:20
So it really should return the same...
I am seeing this.
cat test.hs |./TonHospel
25 x 25 matrix, 8 threads
permanent=-5258461839360 (0.213000 s)
user#user-desktop:~/python$ cat test.hs |./TonHospel |cat -A
25 x 25 matrix, 8 threads$
For some reason cat -A is filtering out part of the output. I guessed it might somehow be related to stderr and stdout so I tried piping both to stdout. This didn't help.
user#user-desktop:~/python$ cat test.hs |./TonHospel 2>&1 |cat -A
25 x 25 matrix, 8 threads$
Last I just randomly tried this.
user#user-desktop:~/python$ cat test.hs |./TonHospel 3>&1 1>&2 2>&3 |cat -A
25 x 25 matrix, 8 threads
permanent=-5258461839360 (0.236000 s)
What is going on? The C++ source code is at https://bpaste.net/show/ce5ca8643ba5 .
You call quick_exit at the end of main, rather than simply returning an exit code. That is extremely dangerous, as quick_exit does not bother to clean up the execution environment. In particular, it does not flush the buffer associated with stdout.
That won't be a problem if stdout is line-buffered, as it will be on most systems if it is attached to a terminal. But if it is fully buffered, as it will be if it is attached to a pipe, then output may be lost, which is what you are seeing.
That's not the only questionable programming practice in your code, but I believe it is the immediate problem.
(By the way, the first line is correctly printed because std::cout << std:::endl; explicitly flushes the cout buffer. Mixing c++ and c output functions is also a bad idea, though.)
When TonHospel detects that its standard output is a terminal, it writes an additional line (such as permanent=-5258461839360 (0.213000 s)) to standard error. Nothing is written to standard error when standard out is something else, such as a pipe or a file.
I'm using gdb to explore a core file on Linux and I noticed weird behavior when examining memory addresses:
(gdb) x/f 0xbd091a10
0xbd091a10: 0
(gdb) x/g 0xbd091a10
0xbd091a10: 65574
(gdb) x/f 0xbd091a10
0xbd091a10: 65574
These statements were run directly back to back, and I don't understand why examining as float returns inconsistent results. The value 65574 does make sense as it corresponds to the identity of the last loaded item by the process.
Does anyone know the reason for this?
Version details:
Linux mx534vm 2.6.18-308.el5 #1 SMP Fri Jan 27 17:17:51 EST 2012 x86_64 x86_64 x86_64 GNU/Linux
GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-32.el5)
There is no inconsistency in this. 'f' and 'g' are specifiers in different categories, 'f' for format and 'g' for unit size. Each specifier, when used, becomes the default for its own category which holds for all subsequent uses of 'x'. Thus, your two last commands are both equivalent to x/fg 0xbd091a10.