I am running an MPI code and I am encountering some strange behavior with MPICH. In the MPI_Irecv call, when I print the source, I found source=-2. and I have this problem only for MPI_Irecv function.
Here, the print result:
MPI_Irecv, Received buffer 0x1398c00, count=1, source=-2, tag=1073741795, MPI processes=4
Could you help me please.
Thank you in advance.
Related
I've written a prime-generating function generatePrimes (full code here) that takes input bound::Int64 and returns a Vector{Int64} of all primes up to bound. After the function definition, I have the following code:
println("Generating primes...")
println("Last prime: ", generatePrimes(10^7)[end])
println("Primes generated.")
which prints, unexpectedly,
Generating primes...
9999991
Primes generated.
This output misses the "Last prime: " segment of the second print statement. The output does work as expected for smaller inputs; any input at least up to 10^6, but somehow fails for 10^7. I've tried several workarounds for this (e.g. assigning the returned value or converting it to a string before calling it in a print statement, combining the print statements, et cetera) and discovered some other weird behaviour: if the "Last prime", is removed from the second print statement, for input 10^7, the last prime doesn't print at all and all I get is a blank line between the first and third print statements. These issues are probably related, and I can't seem to find anything online about why some print statements wouldn't work in Julia.
Thanks so much for any clarification!
Edit: Per DNF's suggestion, following are some reductions to this issue:
Removing the first and last print statements doesn't change anything -- a blank line is always printed in the case I outlined and each of the cases below.
println(generatePrimes(10^7)[end]) # output: empty line
Calling the function and storing the last index in a variable before calling println doesn't change anything either; the cases below work exactly the same either way.
lastPrime::Int = generatePrimes(10^7)[end]
println(lastPrime) # output: empty line
If I call the function in whatever form immediately before a println, an empty line is printed regardless of what's inside the println.
lastPrime::Int = generatePrimes(10^7)[end]
println("This doesn't print") # output: empty line
println("This does print") # output: This does print
If I call the function (or print the pre-generated-and-stored function result) inside a println, anything before the function call (that's also inside the println) isn't printed. The 9999991 and anything else there may be after the function call is printed only if there is something else inside the println before the function call.
# Example 1
println(generatePrimes(10^7)[end]) # output: empty line
# Example 2
println("This first part doesn't print", generatePrimes(10^7)[end]) # output: 9999991
# Example 3
println("This first part doesn't print", generatePrimes(10^7)[end], " prints") # output: 9999991 prints
# Example 4
println(generatePrimes(10^7)[end], "prime doesn't print") # output: prime doesn't print
I could probably list twenty different variations of this same thing, but that probably wouldn't make things any clearer. In every single case version of this issue I've seen so far, the issue only manifests if there's that function call somewhere; println prints large integers just fine. That said, please let me know if anyone feels like they need more info. Thanks so much!
Most likely you are running this code from Atom Juno which recently has some issues with buffering standard output (already reported by others and I also sometimes have this problem).
One thing you can try to do is to flush your standard output
flush(stdout)
Like with any unstable bug restarting Atom Juno also seems to help.
I had the same issue. For me, changing the terminal renderer (File -> Settings -> Packages -> julia-client -> Terminal Options) from webgl to canvas (see pic below) seems to solve the issue.
change terminal renderer
I've also encountered this problem many times. (First time, it was triggered after using the debugger. It is probably unrelated but I have been using Julia+Juno for 2 weeks prior to this issue.)
In my case, the code before the println statement needed to have multiple dictionary assignation (with new keys) in order to trigger the behavior.
I also confirmed that the same code ran in Command Prompt (with same Julia interpreter) prints fine. Any hints about how to further investigate this will be appreciated.
I temporarily solve this issue by printing to stderr, thinking that this stream has more stringent flush mechanism: println(stderr, "hello!")
I have written a basic function for recursively deallocating a trie data structure in C:
// Root pointer is passed as arg in initial call
void destroy(node *trav)
{
for (int i = 0; i < N; i++)
{
if (trav->children[i])
{
destroy(trav->children[i]);
}
}
free(trav);
}
This functions seems to work perfectly fine with any smaller dictionary file. The largest file that the program successfully loaded and unloaded contained 134,480 words.
However, it produces a segmentation fault when deallocating a larger trie. The larger file that causes a segmentation fault contains 506,915 words.
The error message produced by Valgrind states: "Invalid read of size 8" followed by several backtraces and finally; "Address is not stack'd, malloc'd or (recently) free'd".
What might be causing this?
What might be causing this?
Stack overflow might be causing this, although that seems somewhat unlikely: there are almost no locals, so each frame probably only consumes 32 bytes of stack, and that would allow recursion of 8M/32 == 262144 levels deep with Linux default 8MiB stack.
However, if your trie is extremely unbalanced, stack overflow is possible.
You can try ulimit -s unlimited and see if that makes the problem go away.
Or you could run your program under GDB, and examine the instruction at which the SIGSEGV is reported. If it's a CALL, PUSH, or another form of "move to stack", stack overflow is also very likely.
Consider the following code:
File C.jl
module C
export printLength
printLength = function(arr)
println(lentgh(arr))
end
end #module
File Main.jl
using C
main = function()
arr = Array(Int64, 4)
printLength(arr)
end
main()
Let's try to execute it.
$ julia Main.jl
ERROR: lentgh not defined
in include at /usr/bin/../lib64/julia/sys.so
in process_options at /usr/bin/../lib64/julia/sys.so
in _start at /usr/bin/../lib64/julia/sys.so
while loading /home/grzes/julia_sucks/Main.jl, in expression starting on line 8
Obviously, it doesn't compile, because lentgh is misspelled. The problem is the message I received. expression starting on line 8 is simply main(). Julia hopelessly fails to point the invalid code fragment -- it just points to the invocation of main, but the erroneous line is not even in that file! Now imagine a real project where an error hides really deep in the call stack. Julia still wouldn't tell anything more than that the problem started on the entry point of the execution. It is impossible to work like that...
Is there a way to force Julia to give a little more precise messages?
In this case it's almost certainly a consequence of inlining: your printLength function is so short, it's almost certainly inlined into the call site, which is why you get the line number 8.
Eventually, it is expected that inlining won't cause problems for backtraces. At the moment, your best bet---if you're running julia's pre-release 0.4 version---is to start julia as julia --inline=no and run your tests again.
I am very new to IDL so forgive me if this seems dumb. I am trying to simply read a .tif image and let IDL show the image. My commands were:
IDL> a=read_image('frame_1.tif')
IDL> help, a
then I receive
A BYTE = Array[3, 560, 420]
IDL> plotimage ,bytscl(a)
But after I execute the last command, I receive "Keyword parameters not allowed in call."I don't understand what I did wrong. Any ideas?
Thank you in advance.
I'm not sure what is going on, but one thing that seems to generate that error message is that IDL gets confused between arrays (which can use parens to index) and function calls. Try using strictarr before the call:
compile_opt strictarr
This will mean that you must use square brackets to index arrays and parens for function calls.
Note, that you have to put this into every routine (and at the command line) you are having trouble with.
This is regarding compile time argument in openCL.
I have an array of constants of fixed size, and I am passing it as compile-time argument, as follows:
-DCOEFF=0.1f,0.2f,0.5f,0.2f,0.1f
And in the Kernel, I am reading it as,
__kernel void Smoothing(__global const float *in, __global float *out)
{
float chnWeight[] = {COEFF};
}
This way, using intel-SDK, I am getting a considerable amount of performance benefit, compared to passing the Coefficients as another argument to the kernel.
The problem is in AMD, this is not getting compiled. I am getting the following error :
0.2f:
Catastrophic error: cannot open source file "0.2f"
1 catastrophic error detected in the compilation of "0.2f".
Compilation terminated.
I understand that in AMD (comma) is also taken as a separating character for the compile time arguments, and this is causing the error.
Any help to solve this problem will be appreciated. Thanks in advance.
This problem was introduced into AMD OpenCL sometime between versions 937.2 and 1268.1. Here is a work-around:
Replace,
-DCOEFF=0.1f,0.2f,0.5f,0.2f,0.1f
with
-D COEFF=0.1f,0.2f,0.5f,0.2f,0.1f
Try quoting the string to -DCOEFF="0.1f,0.2f,0.5f,0.2f,0.1f"
It looks that the compiler is looking for the file "0.2f" and that is the second element, so after the first element and comma the compiler has already stopped interpreting the input as part of the COEFF define.