I have a simple .c program that makes a call to a function delcared and implemented in the same file.
I compile it using gcc:
gcc myProgram.c -o myProgram -g
Then I use valgrind with callgrind to generate the callgrind.out.* file.
valgrind --tool=callgrind myProgram
Then I use the call grind_annotate
callgrind_annotate callgrind.out.1974
But the result is something similar to what follows and it doesnt include the function call that is in the file. I tried different c code but I get similar results, any idea why?
--------------------------------------------------------------------------------
Profile data file 'callgrind.out.1974' (creator: callgrind-3.8.1)
--------------------------------------------------------------------------------
I1 cache:
D1 cache:
LL cache:
Timerange: Basic block 0 - 34772
Trigger: Program termination
Profiled target: myProgram (PID 1974, part 1)
Events recorded: Ir
Events shown: Ir
Event sort order: Ir
Thresholds: 99
Include dirs:
User annotated:
Auto-annotation: off
--------------------------------------------------------------------------------
Ir
--------------------------------------------------------------------------------
159,723 PROGRAM TOTALS
--------------------------------------------------------------------------------
Ir file:function
--------------------------------------------------------------------------------
51,246 ???:_dl_addr [/lib64/libc-2.5.so]
25,816 ???:do_lookup_x [/lib64/ld-2.5.so]
21,895 ???:_dl_lookup_symbol_x [/lib64/ld-2.5.so]
10,955 ???:_dl_relocate_object [/lib64/ld-2.5.so]
10,487 ???:strcmp'2 [/lib64/ld-2.5.so]
4,974 ???:check_match.8516 [/lib64/ld-2.5.so]
3,885 ???:getenv [/lib64/libc-2.5.so]
1,834 ???:strcmp [/lib64/ld-2.5.so]
1,663 ???:_dl_map_object_from_fd [/lib64/ld-2.5.so]
1,638 ???:strlen [/lib64/ld-2.5.so]
1,382 ???:bsearch [/lib64/libc-2.5.so]
1,323 ???:_dl_name_match_p [/lib64/ld-2.5.so]
1,288 ???:strsep [/lib64/ld-2.5.so]
1,211 ???:_dl_map_object_deps [/lib64/ld-2.5.so]
1,175 ???:dl_main [/lib64/ld-2.5.so]
1,038 ???:_dl_check_map_versions [/lib64/ld-2.5.so]
796 ???:malloc_consolidate [/lib64/libc-2.5.so]
780 ???:strncmp [/lib64/libc-2.5.so]
751 ???:_dl_cache_libcmp'2 [/lib64/ld-2.5.so]
635 ???:__libc_memalign [/lib64/ld-2.5.so]
625 ???:setlocale [/lib64/libc-2.5.so]
624 ???:_nl_find_locale [/lib64/libc-2.5.so]
586 ???:intel_02_known_compare [/lib64/libc-2.5.so]
577 ???:_dl_fixup [/lib64/ld-2.5.so]
576 ???:_dl_new_object [/lib64/ld-2.5.so]
543 ???:memset [/lib64/ld-2.5.so]
528 ???:index [/lib64/ld-2.5.so]
489 ???:_dl_fini [/lib64/ld-2.5.so]
471 ???:match_symbol [/lib64/ld-2.5.so]
469 ???:open_verify [/lib64/ld-2.5.so]
450 ???:memcpy [/lib64/ld-2.5.so]
427 ???:_dl_map_object [/lib64/ld-2.5.so]
415 ???:intel_check_word [/lib64/libc-2.5.so]
400 ???:_int_malloc [/lib64/libc-2.5.so]
395 ???:mempcpy [/lib64/ld-2.5.so]
392 ???:_dl_sysdep_start [/lib64/ld-2.5.so]
375 ???:_dl_start [/lib64/ld-2.5.so]
370 ???:ptmalloc_init [/lib64/libc-2.5.so]
348 ???:new_composite_name [/lib64/libc-2.5.so]
340 ???:_dl_load_cache_lookup [/lib64/ld-2.5.so]
331 ???:_dl_next_ld_env_entry [/lib64/ld-2.5.so]
301 ???:open_path [/lib64/ld-2.5.so]
279 ???:process_envvars [/lib64/ld-2.5.so]
279 ???:_dl_important_hwcaps [/lib64/ld-2.5.so]
278 ???:_dl_init_paths [/lib64/ld-2.5.so]
225 ???:_dl_runtime_resolve [/lib64/ld-2.5.so]
188 ???:_dl_sort_fini [/lib64/ld-2.5.so]
165 ???:_dl_cache_libcmp [/lib64/ld-2.5.so]
164 ???:call_init [/lib64/ld-2.5.so]
135 ???:fillin_rpath [/lib64/ld-2.5.so]
118 ???:handle_intel [/lib64/libc-2.5.so]
114 ???:malloc [/lib64/ld-2.5.so]
109 ???:init_cacheinfo [/lib64/libc-2.5.so]
109 ???:_IO_un_link [/lib64/libc-2.5.so]
108 ???:_dl_catch_error [/lib64/ld-2.5.so]
96 ???:_dl_setup_hash [/lib64/ld-2.5.so]
94 ???:_dl_add_to_namespace_list [/lib64/ld-2.5.so]
81 ???:_IO_flush_all_lockp [/lib64/libc-2.5.so]
79 ???:_dl_check_all_versions [/lib64/ld-2.5.so]
76 ???:set_binding_values [/lib64/libc-2.5.so]
75 ???:__new_exitfn [/lib64/libc-2.5.so]
73 ???:_dl_allocate_tls_init [/lib64/ld-2.5.so]
73 ???:_dl_init [/lib64/ld-2.5.so]
72 ???:calloc [/lib64/ld-2.5.so]
65 ???:exit [/lib64/libc-2.5.so]
65 ???:fclose##GLIBC_2.2.5 [/lib64/libc-2.5.so]
64 ???:_xstat [/lib64/ld-2.5.so]
63 ???:__sigsetjmp [/lib64/ld-2.5.so]
63 ???:init_tls [/lib64/ld-2.5.so]
59 ???:open [/lib64/ld-2.5.so]
Try to add these options to callgrind_annotate :
callgrind_annotate --threshold=100 --tree=both callgrind.out.*
--tree=both prints, for each functions, their callers and the called functions.
--threshold=100 will print all the events (default is 99% so now your function should be printed)
BTW, these two options can print a very important output, so you can run this command to find your function :
callgrind_annotate --threshold=100 --tree=both callgrind.out.* | grep your_function_name
EDIT 1
That's weird. Can you post your code ?
This is my code :
// myProgram.c
#include <stdio.h>
void foo(int value);
int main(void) {
foo(10);
return 0;
}
void foo(int value) {
printf("%d\n", value);
}
And this is my output :
$ gcc myProgram.c -o myProgram -g
$ valgrind --tool=callgrind ./myProgram
==5551== Callgrind, a call-graph generating cache profiler
==5551== Copyright (C) 2002-2012, and GNU GPL'd, by Josef Weidendorfer et al.
==5551== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==5551== Command: ./myProgram
==5551==
==5551== For interactive control, run 'callgrind_control -h'.
10
==5551==
==5551== Events : Ir
==5551== Collected : 102927
==5551==
==5551== I refs: 102,927
$ callgrind_annotate --threshold=100 --tree=both callgrind.out.5551 | grep "foo"
783 < myProgram.c:foo (1x) [/home/junior/test/myProgram]
1,613 < myProgram.c:foo (1x) [/home/junior/test/myProgram]
11 * myProgram.c:foo [/home/junior/test/myProgram]
2,407 > myProgram.c:foo (1x) [/home/junior/test/myProgram]
Related
I used the website diagrams.net to create a figure with some mathematical expressions. Of course, I can export it how PNG and import it to my Overleaf, but I want to retain the vectorization of the expressions. Because of that, I am trying to import it how PDF inside my Overleaf document.
When I use:
\begin{figure}[tbp!]
\centering
\includegraphics[width=\linewidth]{images/math_structure.pdf}
\caption{My figure description.}
\label{fig:math_structure}
\end{figure}
My figure is shown normally, aparently, but when I zoom in the mathematical expressions I have it:
Another interesting thing I noted is that when I download the PDF from Overleaf and open it using MUPDF the "bold" disappears, but when I open it using Google Chrome or Firefox the "bold" is there yet.
This is a pretty strange thing because I guess it was a problem of embedding font inside the PDF, but my file opens normally in MUPDF. Does anyone know what is happening and how can I resolve it?
I am sharing the math_structure in order to reproduce the problem in the following link: PDF
As an addendum to K J's answer:
looking at each letter there are two objects so although I can not see the shadow within the editor but accept it is there so it must be placed by the text outline generator? here I have moved and coloured some glyphs so the second edge is deliberate but most viewers would not show them as a "GLOW"
Indeed, all those items with a glow are drawn twice in the content stream, once for filling the defining path, once for stroking. E.g. the capital S of "State":
.111484379 0 0 -.111468516 140.764496 314.20746 cm
/G3 gs
55 507 m
55 562.33331 74 609 112 647 c
150 685 193.66666 704 243 704 c
257 704 l
313.66666 704 363 683 405 641 c
426 672 l
429.33334 676.66669 432.66666 681.66669 436 687 c
439.33334 692.33331 442.66666 696.66669 446 700 c
449 704 l
449.66666 704 451 704 453 704 c
455 704 457 704.33331 459 705 c
463 705 l
465 705 468 703 472 699 c
472 462 l
466 456 l
448 456 l
440.66666 456 436.33334 457 435 459 c
433.66666 461 432 467.66666 430 479 c
418.66666 563 385 618.66669 329 646 c
304.33334 656.66669 279.33334 662 254 662 c
218.66666 662 190 650 168 626 c
146 602 135 574 135 542 c
135 519.33331 140.666672 498.66666 152 480 c
163.333328 461.33334 179.33333 446.33334 200 435 c
206.66667 432.33334 235.33333 424.66666 286 412 c
336.66666 399.33334 364.66666 391.66666 370 389 c
408 374.33334 439 349.33334 463 314 c
487 278.66666 499.33334 237.66667 500 191 c
500 137 482.66666 88.333336 448 45 c
413.33334 1.66666412 364.33334 -20.333334 301 -21 c
263.66666 -21 230.33333 -15.333334 201 -4 c
171.66667 7.333334 151.333328 17.666666 140 27 c
122 41 l
119.333336 37.666668 114.333336 31 107 21 c
99.666664 11 93 1.66666698 87 -7 c
81 -15.666667 78 -20.333334 78 -21 c
76.666664 -21.666666 73.333336 -22 68 -22 c
64 -22 l
62 -22 59 -20 55 -16 c
55 101 l
55 180.33334 55.333332 220.66667 56 222 c
57.333332 225.33333 64 227 76 227 c
89 227 l
93 223 95 218.66667 95 214 c
95 192.66667 98.333336 171.66667 105 151 c
111.666664 130.333328 123 110 139 90 c
155 70 177 54 205 42 c
233 30 266.33334 24 305 24 c
336.33334 24 363.33334 36.666664 386 62 c
408.66666 87.333336 420 118.333328 420 155 c
420 183.66667 412.66666 209.66667 398 233 c
383.33334 256.33334 364 272.33334 340 281 c
302.66666 290.33334 278 296.66666 266 300 c
262.66666 300.66666 253.66667 302.66666 239 306 c
224.33333 309.33334 213.33333 312 206 314 c
198.66667 316 188 319.66666 174 325 c
160 330.33334 149 336.33334 141 343 c
133 349.66666 123.333336 357.66666 112 367 c
100.666664 376.33334 91.666664 388 85 402 c
65 434.66666 55 469.66666 55 507 c
h
f
/G7 gs
55 507 m
55 562.33331 74 609 112 647 c
150 685 193.66666 704 243 704 c
257 704 l
313.66666 704 363 683 405 641 c
426 672 l
429.33334 676.66669 432.66666 681.66669 436 687 c
439.33334 692.33331 442.66666 696.66669 446 700 c
449 704 l
449.66666 704 451 704 453 704 c
455 704 457 704.33331 459 705 c
463 705 l
465 705 468 703 472 699 c
472 462 l
466 456 l
448 456 l
440.66666 456 436.33334 457 435 459 c
433.66666 461 432 467.66666 430 479 c
418.66666 563 385 618.66669 329 646 c
304.33334 656.66669 279.33334 662 254 662 c
218.66666 662 190 650 168 626 c
146 602 135 574 135 542 c
135 519.33331 140.666672 498.66666 152 480 c
163.333328 461.33334 179.33333 446.33334 200 435 c
206.66667 432.33334 235.33333 424.66666 286 412 c
336.66666 399.33334 364.66666 391.66666 370 389 c
408 374.33334 439 349.33334 463 314 c
487 278.66666 499.33334 237.66667 500 191 c
500 137 482.66666 88.333336 448 45 c
413.33334 1.66666412 364.33334 -20.333334 301 -21 c
263.66666 -21 230.33333 -15.333334 201 -4 c
171.66667 7.333334 151.333328 17.666666 140 27 c
122 41 l
119.333336 37.666668 114.333336 31 107 21 c
99.666664 11 93 1.66666698 87 -7 c
81 -15.666667 78 -20.333334 78 -21 c
76.666664 -21.666666 73.333336 -22 68 -22 c
64 -22 l
62 -22 59 -20 55 -16 c
55 101 l
55 180.33334 55.333332 220.66667 56 222 c
57.333332 225.33333 64 227 76 227 c
89 227 l
93 223 95 218.66667 95 214 c
95 192.66667 98.333336 171.66667 105 151 c
111.666664 130.333328 123 110 139 90 c
155 70 177 54 205 42 c
233 30 266.33334 24 305 24 c
336.33334 24 363.33334 36.666664 386 62 c
408.66666 87.333336 420 118.333328 420 155 c
420 183.66667 412.66666 209.66667 398 233 c
383.33334 256.33334 364 272.33334 340 281 c
302.66666 290.33334 278 296.66666 266 300 c
262.66666 300.66666 253.66667 302.66666 239 306 c
224.33333 309.33334 213.33333 312 206 314 c
198.66667 316 188 319.66666 174 325 c
160 330.33334 149 336.33334 141 343 c
133 349.66666 123.333336 357.66666 112 367 c
100.666664 376.33334 91.666664 388 85 402 c
65 434.66666 55 469.66666 55 507 c
h
S
The filled version is drawn with the extended graphics state G3, the stroked version is drawn with the extended graphics state G7.
G3 fills in an opaque manner:
<</BM/Normal/ca 1>
but G7 strokes very transparently (opacity .1098) and sets some other parameters:
<</BM/Normal/CA .1098/LC 0/LJ 0/LW 0/ML 4/SA true/ca .1098>>
But in particular G7 also sets the line width to 0 (the thinnest line that can be rendered at device resolution: 1 device pixel wide).
The OP mentions that they see the shadows when they zoom in. Thus, maybe those viewers in which you see a broad shadow/glow after zooming do simply zoom by drawing everything magnified by the zoom factor, i.e. the shadow/glow becomes zoom factor * 1 pixel wide; and those viewers in which you don't see a broad shadow/glow draw the outlines even after zooming with a 1 pixel width.
It does not appear to be the difference is in the font style since the weighting between standard 24 and bold 24 is shown below on the right. Which is not evident in your two samples.
However, what is noticeable in your sample is the "shadows" around each of those letter on the left giving the impression of extra thickness.
Initially I would expect that could be caused by the difference between jpeg (haloed lettering) and png (crisp anti-alias outlines). But then the shadow is too regular i.e. not uneven like it would normally be in a jpeg.
At this stage it looks like there may be some other reason for such fuzzy fonts.
Without a sample I would have to guess the PDF has potentially a font with an alpha component but could be way off in such a wild assumption.
Later Edit
Thanks for your link but the mystery deepens, since that linked PDF in Chromium Edge even enlarged shows no evidence of any shadows, but then again the maths looks like vector outlines only the middle Tahoma appears to be font and the one embedded, as generated by Skia/PDF thus built by chrome?.
I have to agree there is some other influence somewhere down the line but the browser should not affect the PDF unless it adds or respects some overlay based on an extra component, and looking at each letter there are two objects so although I can not see the shadow within the editor but accept it is there so it must be placed by the text outline generator?
here I have moved and coloured some glyphs so the second edge is deliberate but most viewers would not show them as a "GLOW"
You mentioned "diagrams.net" which does have many shadow options but I never experienced any other than deliberately set to right and down. Perhaps look for a rogue setting there.
In summary the file is declared as compatible with version 1.4 (may have transparency) and clearly some transparent objects have been included around each letter! but not in a fashion expected by all viewers. As a result of #mkl 's observation I retested the pdf in many viewers with the settings that could have an effect such as vector line thickening in acrobat, However NONE I tested showed the extra thick outlines, thus the PDF seems valid but some PDF viewer(apps) methods you are using seem to thicken the anti-alias much more than should be expected for a single pixel boundary.
I have a file called sds
$head sds
2557 386 fs://name/user/hive/ware/doc1/do_fact/date=20190313/fact=6
2593 393 fs://name/user/hive/ware/toc1/do_gas/idi_centr=6372/mes=20
2594 343 fs://name/user/hive/ware/dac2/do_gas2/idi_centr=6354/mes=21
349 307 fs://name/user/hive/ware/tec2/do_des/mes=25
340 332 fs://name/user/hive/ware/dc1/venta/year=2018/month=12
I want delete /user/hive/ware and replace $7 ~ /_1$ for 1and other $7 for 2 using awk.
The code that I used was:
awk -F"/" '{ if ($7 ~ /_1$/)
print $1"//"$3"/1/"$7-$NF
else
print $1"//"$3"/2/"$7-$NF}' sds
but the result is bad.
I would like and output like:
2557 386 fs://name/1/do_fact/date=20190313/fact=6
2593 393 fs://name/1/do_gas/idi_centr=6372/mes=20
2594 343 fs://name/2/do_gas2/idi_centr=6354/mes=21
349 307 fs://name/2/do_des/mes=25
340 332 fs://name/1/venta/year=2018/month=12
$ awk 'BEGIN{FS=OFS="/"} {sub("/user/hive/ware",""); $4=($4~/1$/ ? 1 : 2)} 1' file
2557 386 fs://name/1/do_fact/date=20190313/fact=6
2593 393 fs://name/1/do_gas/idi_centr=6372/mes=20
2594 343 fs://name/2/do_gas2/idi_centr=6354/mes=21
349 307 fs://name/2/do_des/mes=25
340 332 fs://name/1/venta/year=2018/month=12
or if you don't REALLY want to remove the string /user/hive/share and instead want to remove the 4th through 6th fields no matter their value:
$ awk 'BEGIN{FS=OFS="/"} {$4=$5=$6="\n"; sub(/(\/\n){3}/,""); $4=($4~/1$/ ? 1 : 2)} 1' file
2557 386 fs://name/1/do_fact/date=20190313/fact=6
2593 393 fs://name/1/do_gas/idi_centr=6372/mes=20
2594 343 fs://name/2/do_gas2/idi_centr=6354/mes=21
349 307 fs://name/2/do_des/mes=25
340 332 fs://name/1/venta/year=2018/month=12
with sed
$ sed -E 's_/user/hive/ware/[^/]+(.)/_/\1/_' file
2557 386 fs://name/1/do_fact/date=20190313/fact=6
2593 393 fs://name/1/do_gas/idi_centr=6372/mes=20
2594 343 fs://name/2/do_gas2/idi_centr=6354/mes=21
349 307 fs://name/2/do_des/mes=25
340 332 fs://name/1/venta/year=2018/month=12
it's not really a conditional replacement.
You can use awk and its gsub function to perform replacement on the selected columns.
awk 'BEGIN{FS=OFS="/"}{gsub("user/hive/ware/","");gsub(/^[^12]+/,"",$4)}1' inputfile
2557 386 fs://name/1/do_fact/date=20190313/fact=6
2593 393 fs://name/1/do_gas/idi_centr=6372/mes=20
2594 343 fs://name/2/do_gas2/idi_centr=6354/mes=21
349 307 fs://name/2/do_des/mes=25
340 332 fs://name/1/venta/year=2018/month=12
This question already has an answer here:
MPI_Recv overwrites parts of memory it should not access
(1 answer)
Closed 7 years ago.
Despite having written long, heavily parallelized codes with complicated send/receives over three dimensional arrays, this simple code with a two dimensional array of integers has got me at my wits end. I combed stackoverflow for possible solutions and found one that resembled slightly with the issue I am having:
Boost.MPI: What's received isn't what was sent!
However the solutions seem to point the looping segment of code as the culprit for overwriting sections of the memory. But this one seems to act even stranger. Maybe it is a careless oversight of some simple detail on my part. The problem is with the below code:
program main
implicit none
include 'mpif.h'
integer :: i, j
integer :: counter, offset
integer :: rank, ierr, stVal
integer, dimension(10, 10) :: passMat, prntMat !! passMat CONTAINS VALUES TO BE PASSED TO prntMat
call MPI_INIT(ierr)
call MPI_COMM_RANK(MPI_COMM_WORLD, rank, ierr)
counter = 0
offset = (rank + 1)*300
do j = 1, 10
do i = 1, 10
prntMat(i, j) = 10 !! prntMat OF BOTH RANKS CONTAIN 10
passMat(i, j) = offset + counter !! passMat OF rank=0 CONTAINS 300..399 AND rank=1 CONTAINS 600..699
counter = counter + 1
end do
end do
if (rank == 1) then
call MPI_SEND(passMat(1:10, 1:10), 100, MPI_INTEGER, 0, 1, MPI_COMM_WORLD, ierr) !! SEND passMat OF rank=1 to rank=0
else
call MPI_RECV(prntMat(1:10, 1:10), 100, MPI_INTEGER, 1, 1, MPI_COMM_WORLD, stVal, ierr)
do i = 1, 10
print *, prntMat(:, i)
end do
end if
call MPI_FINALIZE(ierr)
end program main
When I compile the code with mpif90 with no flags and run it on my machine with mpirun -np 2, I get the following output with wrong values in the first four indices of the array:
0 0 400 0 604 605 606 607 608 609
610 611 612 613 614 615 616 617 618 619
620 621 622 623 624 625 626 627 628 629
630 631 632 633 634 635 636 637 638 639
640 641 642 643 644 645 646 647 648 649
650 651 652 653 654 655 656 657 658 659
660 661 662 663 664 665 666 667 668 669
670 671 672 673 674 675 676 677 678 679
680 681 682 683 684 685 686 687 688 689
690 691 692 693 694 695 696 697 698 699
However, when I compile it with the same compiler but with the -O3 flag on, I get the correct output:
600 601 602 603 604 605 606 607 608 609
610 611 612 613 614 615 616 617 618 619
620 621 622 623 624 625 626 627 628 629
630 631 632 633 634 635 636 637 638 639
640 641 642 643 644 645 646 647 648 649
650 651 652 653 654 655 656 657 658 659
660 661 662 663 664 665 666 667 668 669
670 671 672 673 674 675 676 677 678 679
680 681 682 683 684 685 686 687 688 689
690 691 692 693 694 695 696 697 698 699
This error is machine dependent. This issue turns up only on my system running Ubuntu 14.04.2, using OpenMPI 1.6.5
I tried this on other systems running RedHat and CentOS and the code ran well with and without the -O3 flag. Curiously those machines use an older version of OpenMPI - 1.4
I am guessing that the -O3 flag is performing some odd optimization that is modifying the manner in which arrays are being passed between the processes.
I also tried other versions of array allocation. The above code uses explicit shape arrays. With assumed shape and allocated arrays I am receiving equally, if not more bizarre results, with some of them seg-faulting. I tried using Valgrind to trace the origin of these seg-faults, but I still haven't gotten the hang of getting Valgrind to not give false positives when running with MPI programs.
I believe that resolving the difference in performance of the above code will help me understand the tantrums of my other codes as well.
Any help would be greatly appreciated! This code has really gotten me questioning if all the other MPI codes I wrote are sound at all.
Using the Fortran 90 interface to MPI reveals a mismatch in your call to MPI_RECV
call MPI_RECV(prntMat(1:10, 1:10), 100, MPI_INTEGER, 1, 1, MPI_COMM_WORLD, stVal, ierr)
1
Error: There is no specific subroutine for the generic ‘mpi_recv’ at (1)
This is because the status variable stVal is an integer scalar, rather than an array of MPI_STATUS_SIZE. The F77 interface (include 'mpif.h') to MPI_RECV is:
INCLUDE ’mpif.h’
MPI_RECV(BUF, COUNT, DATATYPE, SOURCE, TAG, COMM, STATUS, IERROR)
<type> BUF(*)
INTEGER COUNT, DATATYPE, SOURCE, TAG, COMM
INTEGER STATUS(MPI_STATUS_SIZE), IERROR
Changing
integer :: rank, ierr, stVal
to
integer :: rank, ierr, stVal(mpi_status_size)
produces a program that works as expected, tested with gfortran 5.1 and OpenMPI 1.8.5.
Using the F90 interface (use mpi vs include "mpif.h") lets the compiler detect the mismatched arguments at compile time rather than producing confusing runtime problems.
Note: I've already read the very good answer to this question, but it doesn't answer my issues.
I'm attempting to implement SCRAM-SHA1 authentication standard, as specified by RFC 5802, in Common Lisp. I am running into issues when it comes to generating the client final response message.
This is the code of the function (the rest of the functions are available here) -- this is an attempt to implement the algorithm as described on page 7 of the RFC:
(defun gen-client-final-message
(&key password client-nonce client-initial-message server-response)
(check-type client-nonce string)
(check-type client-initial-message string)
(check-type server-response string)
(check-type password string)
"Takes a password, the initial client nonce, the initial client message & the server response.
Generates the final client message, and returns it along with the server signature."
(progn
(if (eq nil (parse-server-nonce :nonce client-nonce :response server-response)) NIL)
(let* ((final-message-bare (format nil "c=biws,r=~a" (parse-server-nonce :nonce client-nonce
:response server-response)))
(salted-password (ironclad:pbkdf2-hash-password
(ironclad:ascii-string-to-byte-array password)
:salt (ironclad:ascii-string-to-byte-array
(parse-server-salt :response server-response))
:digest :sha1
:iterations (parse-server-iterations :response server-response)))
(client-key (gen-hmac-digest :key salted-password
:message (ironclad:ascii-string-to-byte-array "Client Key")))
(stored-key (gen-sha1-digest :key client-key))
(auth-message (format nil "~a,~a,~a"
client-initial-message
server-response
final-message-bare))
(client-signature (gen-hmac-digest :key stored-key
:message (ironclad:ascii-string-to-byte-array auth-message)))
(client-proof (integer->bit-vector (logxor (ironclad:octets-to-integer client-key)
(ironclad:octets-to-integer client-signature))))
(server-key (gen-hmac-digest :key salted-password
:message (ironclad:ascii-string-to-byte-array "Server Key")))
(server-signature (gen-hmac-digest :key server-key
:message (ironclad:ascii-string-to-byte-array auth-message)))
(final-message (format nil "~a,p=~a"
final-message-bare
(base64-encode (write-to-string client-proof)))))
(pairlis '(final-message
final-message-bare
salted-password
client-key
stored-key
auth-message
client-signature
client-proof
server-key
server-signature)
(list final-message
final-message-bare
salted-password
client-key
stored-key
auth-message
client-signature
client-proof
server-key
server-signature)))))
The example conversation in the RFC uses the username user and the password pencil:
C: n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL
S: r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,
i=4096
C: c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,
p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts=
S: v=rmF9pqV8S7suAoZWja4dJRkFsKQ=
Taking the same server response (r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,i=4096) and feeding it into my function, I get:
* (cl-scram:gen-client-final-message :password "pencil" :client-nonce "fyko+d2lbbFgONRv9qkxdawL" :client-initial-message "n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL" :server-response "r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,i=4096")
((CL-SCRAM::SERVER-SIGNATURE
. #(33 115 21 228 67 190 35 238 223 122 117 125 222 242 209 136 175 228 67
151))
(CL-SCRAM::SERVER-KEY
. #(15 224 146 88 179 172 133 43 165 2 204 98 186 144 62 170 205 191 125 49))
(CL-SCRAM::CLIENT-PROOF
. #*1100100111101011000000111010100000010101011001000101011100110001111100001100100010001101001000110101001010101010001011111000100011100001001110100001001110000)
(CL-SCRAM::CLIENT-SIGNATURE
. #(251 9 164 14 244 111 236 112 227 116 148 143 243 255 231 75 58 114 21
88))
(CL-SCRAM::AUTH-MESSAGE
. "n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,i=4096,c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j")
(CL-SCRAM::STORED-KEY
. #(233 217 70 96 195 157 101 195 143 186 217 28 53 143 20 218 14 239 43
214))
(CL-SCRAM::CLIENT-KEY
. #(226 52 196 123 246 195 102 150 221 109 133 43 153 170 162 186 38 85 87
40))
(CL-SCRAM::SALTED-PASSWORD
. #(29 150 238 58 82 155 90 95 158 71 192 31 34 154 44 184 166 225 95 125))
(CL-SCRAM::FINAL-MESSAGE-BARE
. "c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j")
(CL-SCRAM::FINAL-MESSAGE
. "c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,p=IyoxMTAwMTAwMTExMTAxMDExMDAwMDAwMTExMDEwMTAwMDAwMDEwMTAxMDExMDAxMDAwMTAxMDExMTAwMTEwMDAxMTExMTAwMDAxMTAwMTAwMDEwMDAxMTAxMDAxMDAwMTEwMTAxMDAxMDEwMTAxMDEwMDAxMDExMTExMDAwMTAwMDExMTAwMDAxMDAxMTEwMTAwMDAxMDAxMTEwMDAw"))
As you can see, my client-proof (the p= part of the final-message) is wildly different to the one in the example.
I added all of the intermediate variables to the return in case anyone here can see what's going wrong. Unfortunately, there are no examples which show the intermediate variable values, so I can't compare what I'm getting to the alternatives.
The intermediate values for the sample in the RFC 5802: Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms are on the bottom of this answer.
Your p value is way too long; you are probably encoding the bits as string instead of bytes. You should loop over the byte blocks and XOR each unsigned byte separately. Converting to integer, then to bit string, then back to octet string is going to fail because it will probably remove the most significant zero bits. Once you've got the XOR'ed octet string you can base 64 encode it.
Furthermore, you need to remove n,, from the start of your AuthMessage, as specified in the RFC.
For future developers, without further ado, the intermediate values:
In base 64:
SaltedPassword: HZbuOlKbWl+eR8AfIposuKbhX30=
ClientKey: 4jTEe/bDZpbdbYUrmaqiuiZVVyg=
StoredKey: 6dlGYMOdZcOPutkcNY8U2g7vK9Y=
AuthMessage: n=user,r=fyko+d2lbbFgONRv9qkxdawL,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,i=4096,c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j
ClientSignature: XXE4xIawv6vfSePi2ovW5cedthM=
ClientProof: v0X8v3Bz2T0CJGbJQyF0X+HI4Ts=
Using decimal arrays:
SaltedPassword: 29 150 238 58 82 155 90 95 158 71 192 31 34 154 44 184 166 225 95 125
ClientKey: 226 52 196 123 246 195 102 150 221 109 133 43 153 170 162 186 38 85 87 40
StoredKey: 233 217 70 96 195 157 101 195 143 186 217 28 53 143 20 218 14 239 43 214
AuthMessage: n=user,r=fyko+d2lbbFgONRv9qkxdawL,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,i=4096,c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j
ClientSignature: 93 113 56 196 134 176 191 171 223 73 227 226 218 139 214 229 199 157 182 19
ClientProof: 191 69 252 191 112 115 217 61 2 36 102 201 67 33 116 95 225 200 225 59
I get syntax error while running this script in AMPL. Can someone help me to solve this?
param K;
param N;
param PT;
param beta_lower{1..K};
param beta_upper{1..K};
set KSET := {1 . . K};
set NSET := {1 . . N};
param Channel {KSET,NSET};
var V
var C {KSET, NSET} binary;
#==================================
data;
param K:=2;
param N:=64;
param PT:= 1;
param beta_lower:= 1 1.99 2 3.99;
param beta_upper:= 1 2.01 2 4.01;
param Channel : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 :=
1 1366 1474 1583 1690 1790 1881 1963 2036 2101 2161 2217 2268 2315 2355 2385 2402 2403 2386 2350 2295 2223 2137 2041 1939 1835 1734 1639 1553 1479 1419 1375 1347 1335 1339 1357 1386 1421 1459 1494 1523 1542 1548 1540 1520 1490 1451 1409 1364 1321 1279 1239 1201 1164 1127 1092 1060 1034 1016 1012 1024 1055 1107 1178 1265
2 1297 1281 1250 1201 1135 1055 963 867 772 685 611 555 519 504 510 536 579 636 702 775 851 928 1002 1074 1143 1209 1276 1345 1420 1503 1596 1698 1808 1921 2033 2137 2225 2290 2327 2333 2309 2256 2180 2089 1989 1890 1796 1712 1641 1582 1533 1493 1458 1425 1393 1364 1337 1314 1298 1289 1288 1292 1297 1301;
I write this piece of code in tex file (.rtf) and upload this to neos-server
The output from the solver is:
amplin, line 7 (offset 54):
syntax error
context: >>> {\ <<< rtf1\ansi\ansicpg1252\cocoartf12processing commands.
Executing on neos-2.neos-server.org
Error (2) in /opt/ampl/ampl -R amplin
The problem is that you mix syntax for AMPL model and data in your code. In particular, you should first declare parameter beta_lower in the model:
param beta_lower{1..K}; # you may want a different indexing expression here
and then provide data for it in the data section:
data;
param beta_lower:= 1 1.99 2 3.99;
Your updated formulation looks correct, but the error indicates that it is in RTF format. To make it work you should convert it into plain text.