Re: cyg_drv_dsr_lock usage

Anyone?

--

-- 
Mike

Re: Configtool segfaults

Hello,

  I compiled the configtool on my amd64 system (freebsd). After changing some
  int* casts to intptr_t compiling the configtool worked. (Any interests in
  the diff?)
  However - starting the configtool out of a long directory lead to a
  segfault. I traced down the problem to the String::vFormat function

void String::vFormat(LPCTSTR  pszFormat, va_list marker)
{
   for(int nLength=100;nLength;) {
     TCHAR *buf=new TCHAR[1+nLength];
     int n=_vsntprintf(buf, nLength, pszFormat, marker );
     if(-1==n){
       nLength*=2;  // NT behavior
     } else if (n<nLength){
       string::operator=(buf);
       nLength=0;   // trigger exit from loop
     } else {
       nLength=n+1; // UNIX behavior generally, or NT behavior when buffer 
size exactly matches required length
     }
     delete [] buf;
   }
}

When the for-loop runs the second time (which occurs when the output string 
is longer that 100 chars) the _vsntprintf function is called a second time. 
This is not allowed because the va_list argument marker has  already 
consumed during the first call.

Re: cyg_drv_dsr_lock usage

On Thu, 6 Oct 2011, Michael Bergandi wrote:

> Anyone?

[story entirely]
http://ecos.sourceware.org/ml/ecos-devel/2011-09/msg00003.html

That's what I+Google found. There was one expert explanation by the
topic in the ecos-discuss list

http://ecos.sourceware.org/ml/ecos-discuss/2003-03/msg00178.html

It seems to me that in some cases you would get more help (=hands)
through the eCos discuss list and ... search engines 

Thus, I found/saw no issues with in the posted snippet of the code.

Sergei

Patch for configtool

Hello,

as I wrote some days before I found a bug in the configtool. I attached a 
patch file that fix the long message issue and make the whole source 
compatible to x64 systems. Therefore I replaced the pointer to int casts.

Best regards,
  Martin L.

? patch_file
? tools/configtool/standalone/unix/typescript
? tools/configtool/standalone/wxwin/ct-build-debug
Index: tools/Utils/common/Collections.cpp
===================================================================
RCS file: /cvs/ecos/ecos/host/tools/Utils/common/Collections.cpp,v
retrieving revision 1.4
diff -u -r1.4 Collections.cpp
--- tools/Utils/common/Collections.cpp	29 Jan 2009 17:47:49 -0000	1.4
+++ tools/Utils/common/Collections.cpp	12 Oct 2011 10:54:59 -0000
 <at>  <at>  -47,9 +47,12  <at>  <at> 

 void String::vFormat(LPCTSTR  pszFormat, va_list marker)
 {
+va_list tmp; //tempoary store marker to call vsntprintf more than one time
+
   for(int nLength=100;nLength;) {
+va_copy(tmp,marker);
     TCHAR *buf=new TCHAR[1+nLength];
-    int n=_vsntprintf(buf, nLength, pszFormat, marker ); 

Re: Patch for configtool

Martin Laabs wrote:

> Hello,

Hi Martin,

> as I wrote some days before I found a bug in the configtool. I attached a
> patch file that fix the long message issue and make the whole source
> compatible to x64 systems. Therefore I replaced the pointer to int casts.

Thank you for your contribution and testing. Could you, please, submit a
bug report to eCos Bugzilla system?

http://ecos.sourceware.org/problemreport.html
http://bugs.ecos.sourceware.org/enter_bug.cgi?product=eCos

Thank you,
Sergei

> Best regards,
>  Martin L.
> 

Synth target spawning external processes

Hello

I was wondering if anyone has written some Tcl/Tk code to spawn external 
processes when running the synth target. We currently have a few 
external processes to simulate a GPS receiver among other things. These 
processes are currently started independent of ecossynth and need to be 
up and running when starting the application. This works, but it'd be 
nicer to automatically spawn these processes when the application is 
started, especially when doing so from the debugger. I think I'll wrap 
something up unless there is already a solution out there which I can 
build upon.

Best regards,
Simon

Re: Synth target spawning external processes

On Mon, 17 Oct 2011, Simon Kallweit wrote:

> Hello
> 
> I was wondering if anyone has written some Tcl/Tk code to spawn
> external processes when running the synth target. We currently have a
> few external processes to simulate a GPS receiver among other things.
> These processes are currently started independent of ecossynth and
> need to be up and running when starting the application. This works,
> but it'd be nicer to automatically spawn these processes when the
> application is started, especially when doing so from the debugger. I
> think I'll wrap something up unless there is already a solution out
> there which I can build upon.

Hi Simon,

If I understood you correctly that one (lazy) way is to use ecos target
definition files (.tdf files).  You can put Tcl code there (= what you
need).

My brief test was

  % cat >test.tdf<<EOF
exec notify-send Hello &
exec gksudo &
puts hello
EOF

  % watchdog2 -io -t test.tdf