Re: [jira] [Commented] (PROTON-488) Windows 7 64-bit VS2010 qpid-proton Crash on Startup with Send / Recv Application

2014-03-14 Thread Fraser Adams 

Hi Cliff,
FYI I've just this minute merged all the latest updates to proton-c onto 
the branch I'm using for the JavaScript bindings and have rebuilt 
everything, the changes that you've done for this Jira work beautifully 
for me too!!! Many thanks, you're a star.


Cheers,
Frase

On 28/02/14 08:48, Cliff Jansen wrote:

Sorry for the delay.

I played a bit with emcripten  to see if there was some
misunderstanding going on, but it seems pretty clear that clang knows
exactly what is being passed in via the va_arg call and just plain
refuses to deal with a struct (at least for some architectures).

Consequently the original patch which restricts va_arg processing to
simple types seems to me the most robust and portable solution.  I
will proceed with that for 0.7.

Cliff



a bit indicates to me that clang is not somehow confused about

On Thu, Feb 27, 2014 at 9:01 AM, Fraser Adams
fraser.ad...@blueyonder.co.uk wrote:

Hi again Cliff,
Have you made any progress on this?
Cheers,
Frase


On 30/01/14 02:31, Cliff Jansen wrote:

Well thanks for all that.  I'll certainly take another look and report
back before committing anything.  Giving a compiler family indigestion
is certainly to be avoided.

Cliff

On Tue, Jan 28, 2014 at 11:29 AM, Fraser Adams
fraser.ad...@blueyonder.co.uk wrote:

Hi, me again Cliff.
I've only had time to recheck this against my test case, which is
representative of what I see for real.

Doing:

int pn_data_vfill2(const char *fmt, va_list ap)
{
  // Process the PROPERTIES constant - this seems OK
  uint64_t prop = va_arg(ap, uint64_t);
printf(prop = %llu\n, prop);

  {
  pn_bytes_t bytes = va_arg(ap, pn_bytes_t);
printf(pn_data_vfill z, bytes.size = %zu, bytes.start = %s\n,
bytes.size,
bytes.start);
  }

  // Process the char* returned by pn_string_get()
  {
  char *start = va_arg(ap, char *);
  size_t size = strlen(start);
printf(pn_data_vfill size = %zu\n, size);
printf(pn_data_vfill string = %s\n, start);
  }

  return 0;
}

E.g. the both passing and retrieving structs approach of your second
approach actually doesn't even compile for me with LLVM le32,  I get

error:
cannot compile this aggregate va_arg expression yet
  pn_bytes_t bytes = va_arg(ap, pn_bytes_t);
 ^~
/home/fadams/emscripten/system/include/libc/stdarg.h:15:25: note:
expanded
from
macro 'va_arg'
#define va_arg(v,l) __builtin_va_arg(v,l)
  ^
1 error generated.
ERRORroot: compiler frontend failed to generate LLVM bitcode, halting
make[2]: *** [CMakeFiles/test_varargs.dir/test_varargs.o] Error 1
make[1]: *** [CMakeFiles/test_varargs.dir/all] Error 2
make: *** [all] Error 2

Though it *does* work if I do EMCC_LLVM_TARGET=i386-pc-linux-gnu make


So in a nutshell:
1) if I fudge the LLVM front end pure struct, put  struct retrieve
discrete
and pure discrete values all work correctly.

2) with the standard emscripten le32 LLVM front end (which is what is
recommended)
* pure struct (as above) fails to compile
* put  struct, retrieve discrete (as with the original Proton code) gives
the wrong results - that messed with my head :-)
* pure discrete values (as with your pn_string_size(msg-user_id),
pn_string_get(msg-user_id),) patch works correctly.


So I'd *really* like it if you could go down the path of your original
patch
'cause that would fix what you've been seeing and let me compile the
JavaScript stuff without needing the environment tweaked (which is an
accident waiting to happen). I hope that you are agreeable to that?

I think that it would probably be worth putting a comment in the call to
pn_data_fill and within the pn_data_vfill() 'z' case body to document
that
it's safer to pass individual entries to va_arg to avoid upsetting some
compilers - it's not entirely an *obvious* thing really :-D

Cheers,
Frase




On 27/01/14 21:21, Cliff Jansen wrote:

Thanks for the Javascript related info.

Fraser: can you test if the review board patch (with the struct in
and out strategy) works in your case with the unhacked llvm setup?
If that works then I'll go ahead and check it in.

If it fails, please try the first patch.  If that works, we will just
have to conclude that compilers have trouble with stucts in this case
and fall back to passing the two basic types.  That should be safe to
work in the greatest number of cases.

Many thanks.

On Mon, Jan 27, 2014 at 1:13 PM, Fraser Adams (JIRA) j...@apache.org
wrote:

   [

https://issues.apache.org/jira/browse/PROTON-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13883314#comment-13883314
]

Fraser Adams commented on PROTON-488:
-

Oh to be clear
either struct in and out, or separate size_t and char* in and out

what I meant in my previous comment was that the separate size_t and
char* in and out is what LLVM le32 is

[jira] [Commented] (PROTON-488) Windows 7 64-bit VS2010 qpid-proton Crash on Startup with Send / Recv Application

2014-03-10 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/PROTON-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13925863#comment-13925863
 ] 

ASF subversion and git services commented on PROTON-488:


Commit 1575995 from cliffjan...@apache.org in branch 'proton/trunk'
[ https://svn.apache.org/r1575995 ]

PROTON-488: fix va_arg calls for the z type to always pass two simple types 
instead of a struct. Needed by VS and clang.

 Windows 7 64-bit VS2010 qpid-proton Crash on Startup with Send / Recv 
 Application
 -

 Key: PROTON-488
 URL: https://issues.apache.org/jira/browse/PROTON-488
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Affects Versions: 0.6
 Environment: Windows 7 64-bit VS 2010
Reporter: Frank Quinn
Assignee: Cliff Jansen
Priority: Critical
 Attachments: PROTON-488-0.patch, qpid-proton-win64-send-crash.png


 Steps to recreate:
 1. Grab latest 0.6 tarball
 2. Start up Visual Studio x64 Win64 Command Prompt (2010) and run cmake . 
 to generate the visual studio files
 3. Open Up the newly created Proton.sln in VS2010, right click on qpid-proton 
 and add the path to python to executable directories
 4. In the configuration manager, select qpid-proton and select active 
 configuration to be Debug, then select Add to add x64 support, copying 
 win32 configuration in the process.
 5. Select qpid-proton properties and remove the hard coded /machine:X86 extra 
 command lines in Linker - Command Line (MACHINE:X64 should already be in the 
 command line above so no need to add here)
 6. Right click on qpid-proton and select build
 Repeat steps 3-6 for send / recv applications. When you run recv, then run 
 send, you'll get a crash with the (soon to be attached) trace.
 Cheers,
 Frank



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: [jira] [Commented] (PROTON-488) Windows 7 64-bit VS2010 qpid-proton Crash on Startup with Send / Recv Application

2014-02-27 Thread Fraser Adams 

Hi again Cliff,
Have you made any progress on this?
Cheers,
Frase

On 30/01/14 02:31, Cliff Jansen wrote:

Well thanks for all that.  I'll certainly take another look and report
back before committing anything.  Giving a compiler family indigestion
is certainly to be avoided.

Cliff

On Tue, Jan 28, 2014 at 11:29 AM, Fraser Adams
fraser.ad...@blueyonder.co.uk wrote:

Hi, me again Cliff.
I've only had time to recheck this against my test case, which is
representative of what I see for real.

Doing:

int pn_data_vfill2(const char *fmt, va_list ap)
{
 // Process the PROPERTIES constant - this seems OK
 uint64_t prop = va_arg(ap, uint64_t);
printf(prop = %llu\n, prop);

 {
 pn_bytes_t bytes = va_arg(ap, pn_bytes_t);
printf(pn_data_vfill z, bytes.size = %zu, bytes.start = %s\n, bytes.size,
bytes.start);
 }

 // Process the char* returned by pn_string_get()
 {
 char *start = va_arg(ap, char *);
 size_t size = strlen(start);
printf(pn_data_vfill size = %zu\n, size);
printf(pn_data_vfill string = %s\n, start);
 }

 return 0;
}

E.g. the both passing and retrieving structs approach of your second
approach actually doesn't even compile for me with LLVM le32,  I get

error:
   cannot compile this aggregate va_arg expression yet
 pn_bytes_t bytes = va_arg(ap, pn_bytes_t);
^~
/home/fadams/emscripten/system/include/libc/stdarg.h:15:25: note: expanded
from
   macro 'va_arg'
#define va_arg(v,l) __builtin_va_arg(v,l)
 ^
1 error generated.
ERRORroot: compiler frontend failed to generate LLVM bitcode, halting
make[2]: *** [CMakeFiles/test_varargs.dir/test_varargs.o] Error 1
make[1]: *** [CMakeFiles/test_varargs.dir/all] Error 2
make: *** [all] Error 2

Though it *does* work if I do EMCC_LLVM_TARGET=i386-pc-linux-gnu make


So in a nutshell:
1) if I fudge the LLVM front end pure struct, put  struct retrieve discrete
and pure discrete values all work correctly.

2) with the standard emscripten le32 LLVM front end (which is what is
recommended)
* pure struct (as above) fails to compile
* put  struct, retrieve discrete (as with the original Proton code) gives
the wrong results - that messed with my head :-)
* pure discrete values (as with your pn_string_size(msg-user_id),
pn_string_get(msg-user_id),) patch works correctly.


So I'd *really* like it if you could go down the path of your original patch
'cause that would fix what you've been seeing and let me compile the
JavaScript stuff without needing the environment tweaked (which is an
accident waiting to happen). I hope that you are agreeable to that?

I think that it would probably be worth putting a comment in the call to
pn_data_fill and within the pn_data_vfill() 'z' case body to document that
it's safer to pass individual entries to va_arg to avoid upsetting some
compilers - it's not entirely an *obvious* thing really :-D

Cheers,
Frase




On 27/01/14 21:21, Cliff Jansen wrote:

Thanks for the Javascript related info.

Fraser: can you test if the review board patch (with the struct in
and out strategy) works in your case with the unhacked llvm setup?
If that works then I'll go ahead and check it in.

If it fails, please try the first patch.  If that works, we will just
have to conclude that compilers have trouble with stucts in this case
and fall back to passing the two basic types.  That should be safe to
work in the greatest number of cases.

Many thanks.

On Mon, Jan 27, 2014 at 1:13 PM, Fraser Adams (JIRA) j...@apache.org
wrote:

  [
https://issues.apache.org/jira/browse/PROTON-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13883314#comment-13883314
]

Fraser Adams commented on PROTON-488:
-

Oh to be clear
either struct in and out, or separate size_t and char* in and out

what I meant in my previous comment was that the separate size_t and
char* in and out is what LLVM le32 is happiest with, the structs seem to
confuse it, I hadn't realised that you'd changed your original patch to now
do all 'z' encodings to be passed as a single pn_bytes_t struct and
retrieved as a single pn_bytes_t struct - although this arguably looks
neater I'd definitely prefer your first approach.


Windows 7 64-bit VS2010 qpid-proton Crash on Startup with Send / Recv
Application

-

  Key: PROTON-488
  URL: https://issues.apache.org/jira/browse/PROTON-488
  Project: Qpid Proton
   Issue Type: Bug
   Components: proton-c
 Affects Versions: 0.6
  Environment: Windows 7 64-bit VS 2010
 Reporter: Frank Quinn
 Assignee: Cliff Jansen
 Priority: Critical
  Attachments: PROTON-488-0.patch,
qpid-proton-win64-send-crash.png


Steps to recreate:
1. Grab

Re: [jira] [Commented] (PROTON-488) Windows 7 64-bit VS2010 qpid-proton Crash on Startup with Send / Recv Application

2014-01-29 Thread Cliff Jansen 
Well thanks for all that.  I'll certainly take another look and report
back before committing anything.  Giving a compiler family indigestion
is certainly to be avoided.

Cliff

On Tue, Jan 28, 2014 at 11:29 AM, Fraser Adams
fraser.ad...@blueyonder.co.uk wrote:
 Hi, me again Cliff.
 I've only had time to recheck this against my test case, which is
 representative of what I see for real.

 Doing:

 int pn_data_vfill2(const char *fmt, va_list ap)
 {
 // Process the PROPERTIES constant - this seems OK
 uint64_t prop = va_arg(ap, uint64_t);
 printf(prop = %llu\n, prop);

 {
 pn_bytes_t bytes = va_arg(ap, pn_bytes_t);
 printf(pn_data_vfill z, bytes.size = %zu, bytes.start = %s\n, bytes.size,
 bytes.start);
 }

 // Process the char* returned by pn_string_get()
 {
 char *start = va_arg(ap, char *);
 size_t size = strlen(start);
 printf(pn_data_vfill size = %zu\n, size);
 printf(pn_data_vfill string = %s\n, start);
 }

 return 0;
 }

 E.g. the both passing and retrieving structs approach of your second
 approach actually doesn't even compile for me with LLVM le32,  I get

 error:
   cannot compile this aggregate va_arg expression yet
 pn_bytes_t bytes = va_arg(ap, pn_bytes_t);
^~
 /home/fadams/emscripten/system/include/libc/stdarg.h:15:25: note: expanded
 from
   macro 'va_arg'
 #define va_arg(v,l) __builtin_va_arg(v,l)
 ^
 1 error generated.
 ERRORroot: compiler frontend failed to generate LLVM bitcode, halting
 make[2]: *** [CMakeFiles/test_varargs.dir/test_varargs.o] Error 1
 make[1]: *** [CMakeFiles/test_varargs.dir/all] Error 2
 make: *** [all] Error 2

 Though it *does* work if I do EMCC_LLVM_TARGET=i386-pc-linux-gnu make


 So in a nutshell:
 1) if I fudge the LLVM front end pure struct, put  struct retrieve discrete
 and pure discrete values all work correctly.

 2) with the standard emscripten le32 LLVM front end (which is what is
 recommended)
 * pure struct (as above) fails to compile
 * put  struct, retrieve discrete (as with the original Proton code) gives
 the wrong results - that messed with my head :-)
 * pure discrete values (as with your pn_string_size(msg-user_id),
 pn_string_get(msg-user_id),) patch works correctly.


 So I'd *really* like it if you could go down the path of your original patch
 'cause that would fix what you've been seeing and let me compile the
 JavaScript stuff without needing the environment tweaked (which is an
 accident waiting to happen). I hope that you are agreeable to that?

 I think that it would probably be worth putting a comment in the call to
 pn_data_fill and within the pn_data_vfill() 'z' case body to document that
 it's safer to pass individual entries to va_arg to avoid upsetting some
 compilers - it's not entirely an *obvious* thing really :-D

 Cheers,
 Frase




 On 27/01/14 21:21, Cliff Jansen wrote:

 Thanks for the Javascript related info.

 Fraser: can you test if the review board patch (with the struct in
 and out strategy) works in your case with the unhacked llvm setup?
 If that works then I'll go ahead and check it in.

 If it fails, please try the first patch.  If that works, we will just
 have to conclude that compilers have trouble with stucts in this case
 and fall back to passing the two basic types.  That should be safe to
 work in the greatest number of cases.

 Many thanks.

 On Mon, Jan 27, 2014 at 1:13 PM, Fraser Adams (JIRA) j...@apache.org
 wrote:

  [
 https://issues.apache.org/jira/browse/PROTON-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13883314#comment-13883314
 ]

 Fraser Adams commented on PROTON-488:
 -

 Oh to be clear
 either struct in and out, or separate size_t and char* in and out

 what I meant in my previous comment was that the separate size_t and
 char* in and out is what LLVM le32 is happiest with, the structs seem to
 confuse it, I hadn't realised that you'd changed your original patch to now
 do all 'z' encodings to be passed as a single pn_bytes_t struct and
 retrieved as a single pn_bytes_t struct - although this arguably looks
 neater I'd definitely prefer your first approach.

 Windows 7 64-bit VS2010 qpid-proton Crash on Startup with Send / Recv
 Application

 -

  Key: PROTON-488
  URL: https://issues.apache.org/jira/browse/PROTON-488
  Project: Qpid Proton
   Issue Type: Bug
   Components: proton-c
 Affects Versions: 0.6
  Environment: Windows 7 64-bit VS 2010
 Reporter: Frank Quinn
 Assignee: Cliff Jansen
 Priority: Critical
  Attachments: PROTON-488-0.patch,
 qpid-proton-win64-send-crash.png


 Steps to recreate:
 1. Grab latest 0.6 tarball
 2. Start up Visual

[jira] [Commented] (PROTON-488) Windows 7 64-bit VS2010 qpid-proton Crash on Startup with Send / Recv Application

2014-01-27 Thread Fraser Adams (JIRA) 

[ 
https://issues.apache.org/jira/browse/PROTON-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13883314#comment-13883314
 ] 

Fraser Adams commented on PROTON-488:
-

Oh to be clear
either struct in and out, or separate size_t and char* in and out

what I meant in my previous comment was that the separate size_t and char* in 
and out is what LLVM le32 is happiest with, the structs seem to confuse it, I 
hadn't realised that you'd changed your original patch to now do all 'z' 
encodings to be passed as a single pn_bytes_t struct and retrieved as a 
single pn_bytes_t struct - although this arguably looks neater I'd definitely 
prefer your first approach.

 Windows 7 64-bit VS2010 qpid-proton Crash on Startup with Send / Recv 
 Application
 -

 Key: PROTON-488
 URL: https://issues.apache.org/jira/browse/PROTON-488
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Affects Versions: 0.6
 Environment: Windows 7 64-bit VS 2010
Reporter: Frank Quinn
Assignee: Cliff Jansen
Priority: Critical
 Attachments: PROTON-488-0.patch, qpid-proton-win64-send-crash.png


 Steps to recreate:
 1. Grab latest 0.6 tarball
 2. Start up Visual Studio x64 Win64 Command Prompt (2010) and run cmake . 
 to generate the visual studio files
 3. Open Up the newly created Proton.sln in VS2010, right click on qpid-proton 
 and add the path to python to executable directories
 4. In the configuration manager, select qpid-proton and select active 
 configuration to be Debug, then select Add to add x64 support, copying 
 win32 configuration in the process.
 5. Select qpid-proton properties and remove the hard coded /machine:X86 extra 
 command lines in Linker - Command Line (MACHINE:X64 should already be in the 
 command line above so no need to add here)
 6. Right click on qpid-proton and select build
 Repeat steps 3-6 for send / recv applications. When you run recv, then run 
 send, you'll get a crash with the (soon to be attached) trace.
 Cheers,
 Frank



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Re: [jira] [Commented] (PROTON-488) Windows 7 64-bit VS2010 qpid-proton Crash on Startup with Send / Recv Application

2014-01-27 Thread Cliff Jansen 
Thanks for the Javascript related info.

Fraser: can you test if the review board patch (with the struct in
and out strategy) works in your case with the unhacked llvm setup?
If that works then I'll go ahead and check it in.

If it fails, please try the first patch.  If that works, we will just
have to conclude that compilers have trouble with stucts in this case
and fall back to passing the two basic types.  That should be safe to
work in the greatest number of cases.

Many thanks.

On Mon, Jan 27, 2014 at 1:13 PM, Fraser Adams (JIRA) j...@apache.org wrote:

 [ 
 https://issues.apache.org/jira/browse/PROTON-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13883314#comment-13883314
  ]

 Fraser Adams commented on PROTON-488:
 -

 Oh to be clear
 either struct in and out, or separate size_t and char* in and out

 what I meant in my previous comment was that the separate size_t and char* in 
 and out is what LLVM le32 is happiest with, the structs seem to confuse it, I 
 hadn't realised that you'd changed your original patch to now do all 'z' 
 encodings to be passed as a single pn_bytes_t struct and retrieved as a 
 single pn_bytes_t struct - although this arguably looks neater I'd 
 definitely prefer your first approach.

 Windows 7 64-bit VS2010 qpid-proton Crash on Startup with Send / Recv 
 Application
 -

 Key: PROTON-488
 URL: https://issues.apache.org/jira/browse/PROTON-488
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Affects Versions: 0.6
 Environment: Windows 7 64-bit VS 2010
Reporter: Frank Quinn
Assignee: Cliff Jansen
Priority: Critical
 Attachments: PROTON-488-0.patch, qpid-proton-win64-send-crash.png


 Steps to recreate:
 1. Grab latest 0.6 tarball
 2. Start up Visual Studio x64 Win64 Command Prompt (2010) and run cmake . 
 to generate the visual studio files
 3. Open Up the newly created Proton.sln in VS2010, right click on 
 qpid-proton and add the path to python to executable directories
 4. In the configuration manager, select qpid-proton and select active 
 configuration to be Debug, then select Add to add x64 support, copying 
 win32 configuration in the process.
 5. Select qpid-proton properties and remove the hard coded /machine:X86 
 extra command lines in Linker - Command Line (MACHINE:X64 should already be 
 in the command line above so no need to add here)
 6. Right click on qpid-proton and select build
 Repeat steps 3-6 for send / recv applications. When you run recv, then run 
 send, you'll get a crash with the (soon to be attached) trace.
 Cheers,
 Frank



 --
 This message was sent by Atlassian JIRA
 (v6.1.5#6160)

[jira] [Commented] (PROTON-488) Windows 7 64-bit VS2010 qpid-proton Crash on Startup with Send / Recv Application

2014-01-27 Thread Fraser Adams (JIRA) 

[ 
https://issues.apache.org/jira/browse/PROTON-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13883328#comment-13883328
 ] 

Fraser Adams commented on PROTON-488:
-

For info I managed to pull out the bits that were affecting me as a cut down 
reproducer in a GitHub gist, you might notice something of a familiarity.

https://gist.github.com/fadams/8315263

The  pn_string_get_bytes(),
was what caused me the pain (I tried retrieving the struct too but the only 
things that work were pushing up the separate parts of the struct or messing 
with the LLVM front end) I'd have preferred the former like your original patch 
but hadn't got round to doing that as I could work around it and I had a few 
other things to sort out.



 Windows 7 64-bit VS2010 qpid-proton Crash on Startup with Send / Recv 
 Application
 -

 Key: PROTON-488
 URL: https://issues.apache.org/jira/browse/PROTON-488
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Affects Versions: 0.6
 Environment: Windows 7 64-bit VS 2010
Reporter: Frank Quinn
Assignee: Cliff Jansen
Priority: Critical
 Attachments: PROTON-488-0.patch, qpid-proton-win64-send-crash.png


 Steps to recreate:
 1. Grab latest 0.6 tarball
 2. Start up Visual Studio x64 Win64 Command Prompt (2010) and run cmake . 
 to generate the visual studio files
 3. Open Up the newly created Proton.sln in VS2010, right click on qpid-proton 
 and add the path to python to executable directories
 4. In the configuration manager, select qpid-proton and select active 
 configuration to be Debug, then select Add to add x64 support, copying 
 win32 configuration in the process.
 5. Select qpid-proton properties and remove the hard coded /machine:X86 extra 
 command lines in Linker - Command Line (MACHINE:X64 should already be in the 
 command line above so no need to add here)
 6. Right click on qpid-proton and select build
 Repeat steps 3-6 for send / recv applications. When you run recv, then run 
 send, you'll get a crash with the (soon to be attached) trace.
 Cheers,
 Frank



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (PROTON-488) Windows 7 64-bit VS2010 qpid-proton Crash on Startup with Send / Recv Application

2014-01-27 Thread Fraser Adams (JIRA) 

[ 
https://issues.apache.org/jira/browse/PROTON-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13883472#comment-13883472
 ] 

Fraser Adams commented on PROTON-488:
-

Hey Cliff,
Re can you test if the review board patch (with the struct in and out 
strategy) works in your case with the unhacked llvm setup? - I could check it 
again, though it'll be a couple of days before I can get coding time to try it 
I'm afraid.

I did actually try that approach out previously though on the off-chance - and 
it didn't work, the only two things that worked for me were passing the two 
basic types or messing with the LLVM front end.

I've copied a link to the issue I raised on the emscripten mailing list on 
this, mainly for interest, but you'll note a painful similarity with what 
you've experienced :-D

https://github.com/kripken/emscripten/issues/1988

 Windows 7 64-bit VS2010 qpid-proton Crash on Startup with Send / Recv 
 Application
 -

 Key: PROTON-488
 URL: https://issues.apache.org/jira/browse/PROTON-488
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Affects Versions: 0.6
 Environment: Windows 7 64-bit VS 2010
Reporter: Frank Quinn
Assignee: Cliff Jansen
Priority: Critical
 Attachments: PROTON-488-0.patch, qpid-proton-win64-send-crash.png


 Steps to recreate:
 1. Grab latest 0.6 tarball
 2. Start up Visual Studio x64 Win64 Command Prompt (2010) and run cmake . 
 to generate the visual studio files
 3. Open Up the newly created Proton.sln in VS2010, right click on qpid-proton 
 and add the path to python to executable directories
 4. In the configuration manager, select qpid-proton and select active 
 configuration to be Debug, then select Add to add x64 support, copying 
 win32 configuration in the process.
 5. Select qpid-proton properties and remove the hard coded /machine:X86 extra 
 command lines in Linker - Command Line (MACHINE:X64 should already be in the 
 command line above so no need to add here)
 6. Right click on qpid-proton and select build
 Repeat steps 3-6 for send / recv applications. When you run recv, then run 
 send, you'll get a crash with the (soon to be attached) trace.
 Cheers,
 Frank



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (PROTON-488) Windows 7 64-bit VS2010 qpid-proton Crash on Startup with Send / Recv Application

2014-01-23 Thread Chuck Rolke (JIRA) 

[ 
https://issues.apache.org/jira/browse/PROTON-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13880309#comment-13880309
 ] 

Chuck Rolke commented on PROTON-488:


I never let cmake decide which compiler to use. Even with the x64 Win64 Command 
Prompt cmake is building a 32-bit solution. Try forcing a 64-bit solution with

 cmake -G Visual Studio 10 Win64 .

Getting the correct solution generated by cmake makes changing properties 
(steps 3-6) unnecessary.


 Windows 7 64-bit VS2010 qpid-proton Crash on Startup with Send / Recv 
 Application
 -

 Key: PROTON-488
 URL: https://issues.apache.org/jira/browse/PROTON-488
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Affects Versions: 0.6
 Environment: Windows 7 64-bit VS 2010
Reporter: Frank Quinn
Assignee: Cliff Jansen
Priority: Critical
 Attachments: qpid-proton-win64-send-crash.png


 Steps to recreate:
 1. Grab latest 0.6 tarball
 2. Start up Visual Studio x64 Win64 Command Prompt (2010) and run cmake . 
 to generate the visual studio files
 3. Open Up the newly created Proton.sln in VS2010, right click on qpid-proton 
 and add the path to python to executable directories
 4. In the configuration manager, select qpid-proton and select active 
 configuration to be Debug, then select Add to add x64 support, copying 
 win32 configuration in the process.
 5. Select qpid-proton properties and remove the hard coded /machine:X86 extra 
 command lines in Linker - Command Line (MACHINE:X64 should already be in the 
 command line above so no need to add here)
 6. Right click on qpid-proton and select build
 Repeat steps 3-6 for send / recv applications. When you run recv, then run 
 send, you'll get a crash with the (soon to be attached) trace.
 Cheers,
 Frank



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Re: [jira] [Commented] (PROTON-488) Windows 7 64-bit VS2010 qpid-proton Crash on Startup with Send / Recv Application

2014-01-23 Thread Cliff Jansen 
I can reproduce the problem even when using cmake as recommended.

The problem is proton's fast and loose use of binary data in the
codec.  The assumption that a struct will be placed on the stack a
certain way falls apart in 64bit Visual Studio, so that it is no
longer OK to use either a single argument (pn_data_t struct) or two
separate ones (a size_t and char*), depending on what's convenient at
the time.  The va_arg macro works very differently in 32bit versus
64bit in this case.

I will have a work-around patch soon and will separately work an
official fix through review board and PROTON-488

Cliff

On Thu, Jan 23, 2014 at 12:15 PM, Chuck Rolke (JIRA) j...@apache.org wrote:

 [ 
 https://issues.apache.org/jira/browse/PROTON-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13880309#comment-13880309
  ]

 Chuck Rolke commented on PROTON-488:
 

 I never let cmake decide which compiler to use. Even with the x64 Win64 
 Command Prompt cmake is building a 32-bit solution. Try forcing a 64-bit 
 solution with

 cmake -G Visual Studio 10 Win64 .

 Getting the correct solution generated by cmake makes changing properties 
 (steps 3-6) unnecessary.


 Windows 7 64-bit VS2010 qpid-proton Crash on Startup with Send / Recv 
 Application
 -

 Key: PROTON-488
 URL: https://issues.apache.org/jira/browse/PROTON-488
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Affects Versions: 0.6
 Environment: Windows 7 64-bit VS 2010
Reporter: Frank Quinn
Assignee: Cliff Jansen
Priority: Critical
 Attachments: qpid-proton-win64-send-crash.png


 Steps to recreate:
 1. Grab latest 0.6 tarball
 2. Start up Visual Studio x64 Win64 Command Prompt (2010) and run cmake . 
 to generate the visual studio files
 3. Open Up the newly created Proton.sln in VS2010, right click on 
 qpid-proton and add the path to python to executable directories
 4. In the configuration manager, select qpid-proton and select active 
 configuration to be Debug, then select Add to add x64 support, copying 
 win32 configuration in the process.
 5. Select qpid-proton properties and remove the hard coded /machine:X86 
 extra command lines in Linker - Command Line (MACHINE:X64 should already be 
 in the command line above so no need to add here)
 6. Right click on qpid-proton and select build
 Repeat steps 3-6 for send / recv applications. When you run recv, then run 
 send, you'll get a crash with the (soon to be attached) trace.
 Cheers,
 Frank



 --
 This message was sent by Atlassian JIRA
 (v6.1.5#6160)