wrapper-user — User issues for Wrapper. (Support questions, etc.)

Re: [Wrapper-user] Mac OS X - Segmentation Fault

[Leif M. <le...@ta...>]

Should have been doing more sleeping and less coding :-)

Fixed!

Cheers,
Leif

Mike Castle wrote:

>In article <3E9...@ta...>,
>Leif Mortenson  <wra...@li...> wrote:
>  
>
>>I went through and fixed the code in a few places where I was not setting
>>variables to NULL after they were freed, but none of them looked like they
>>    
>>
>
>
>But you didn't test to see if they compile.  :-/
>
>diff -u -r1.53 wrapper.c
>--- src/c/wrapper.c     15 Apr 2003 14:17:45 -0000      1.53
>+++ src/c/wrapper.c     15 Apr 2003 20:33:37 -0000
>@@ -1123,7 +1123,6 @@
>                         }
> 
>                         globfree(&g);
>-                        g = NULL;
> #endif
>                     } else {
>                         /* Is there room for the entry? */
>
>
>
>g isn't a pointer.
>
>mrc
>
>  
>

Re: [Wrapper-user] Regarding Windows NT service

[Leif M. <le...@ta...>]

Ravi,
    All of my Windows machines are Japanese, so I can't tell you the exact
menu to select in english.  But look in the View menu of the Task Manager.
When viewing the process tab, there is a menu choice which will bring up
a dialog that allows you to select from a number of columns of information
to display.  I always show the user and had forgotten that it was not on
by default.

Cheers,
Leif

Ravi Shankar wrote:

> Hi Leif,
>  
>  How can I see it in Task Manager? When I look at the Task Manager 
> window, I see only process name, PID, memory CPU time etc but no info 
> regarding the user account? Can you please help, thanks.
>  
> Regards
> Ravi

Re: [Wrapper-user] Mac OS X - Segmentation Fault

[<da...@ix...>]

In article <bs4...@th...>,
Mike Castle <wra...@li...> wrote:
>Hmm... I was going to try ElectricFence, but that didn't get me very far.
>Changing console() to do
>exec df $WRAPPER_CMD ...
>And core dump right away.
>
>Running NodeWarrior Analytics Server...
>
>  Electric Fence 2.2.0 Copyright (C) 1987-1999 Bruce Perens
><br...@pe...>
>
>ElectricFence Aborting: Allocating 0 bytes, probably a bug.

Ok, setting EF_ALLOW_MALLOC_0 seems to fix that (bug mabye OSX has issues
with malloc(0); wouldn't think so being BSD derived, but you never know).


But that turned up another issue.  Efence spits out some text on
initialization, which means the first thing wrapper sees is '\n'.
Wrapper was not amused.  I had to do the following patch:

diff -u -r1.33 wrapper_unix.c
--- src/c/wrapper_unix.c        3 Apr 2003 08:10:19 -0000       1.33
+++ src/c/wrapper_unix.c        15 Apr 2003 22:07:03 -0000
@@ -360,6 +360,13 @@
         startTime = now = timeBuffer.time;
         startTimeMillis = nowMillis = timeBuffer.millitm;
 
+        if (childOutputBuffer == NULL) {
+            childOutputBuffer = malloc(1024);
+            if (childOutputBuffer != NULL) {
+                childOutputBufferSize = 1024;
+            }
+        }
+
         /*
         log_printf(WRAPPER_SOURCE_WRAPPER, LEVEL_DEBUG, "now=%ld, nowMillis=%d", now, nowMillis);
         */


Meanwhile, I ran a few tests with wrapper and efence and saw nothing
unusual in the current cvs code.

However, I'd like to suggest one change:

--- src/c/wrapper_unix.c        3 Apr 2003 08:10:19 -0000       1.33
+++ src/c/wrapper_unix.c        15 Apr 2003 22:11:13 -0000
@@ -213,8 +213,8 @@
     /*                        number of arguments + 1 for a NULL pointer
at the end */
     for (i = 0; i <= length; i++) {
         if (i < length) {
-            wrapperData->jvmCommand[i] = (char *)malloc(sizeof(char *) * strlen(strings[i]) + 1);
-            sprintf(wrapperData->jvmCommand[i], strings[i]);
+            wrapperData->jvmCommand[i] = malloc(sizeof(char *) * strlen(strings[i]) + 1);
+            strcpy(wrapperData->jvmCommand[i], strings[i]);
         } else {
             wrapperData->jvmCommand[i] = NULL;
         }

First:  in _C_, one should _NEVER_ cast the return value of malloc().  If
you get warnings without it, your ether your code or compiler is broken.

Second, if strings[i] contains an %, bad things can happen in the sprintf.

mrc
-- 
     Mike Castle      da...@ix...      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

[Wrapper-user] Regarding Windows NT service

[Ravi S. <ra...@el...>]

Hi Leif,
Sorry, it is available in the documentation, thanks.

Regards,
Ravi

[Wrapper-user] Regarding Windows NT service

[Ravi S. <ra...@el...>]

Hi Leif,

 How can I see it in Task Manager? When I look at the Task Manager =
window, I see only process name, PID, memory CPU time etc but no info =
regarding the user account? Can you please help, thanks.

Regards
Ravi

[Wrapper-user] Regarding Windows NT service

[Ravi S. <ra...@el...>]

Hi Leif,
 Thanks for the reply. Let me get back to you after I read and make the =
necessary changes.

Thanks and regards,
Ravi

Re: [Wrapper-user] Mac OS X - Segmentation Fault

[<da...@ix...>]

In article <3E9...@ta...>,
Leif Mortenson  <wra...@li...> wrote:
>I went through and fixed the code in a few places where I was not setting
>variables to NULL after they were freed, but none of them looked like they


But you didn't test to see if they compile.  :-/

diff -u -r1.53 wrapper.c
--- src/c/wrapper.c     15 Apr 2003 14:17:45 -0000      1.53
+++ src/c/wrapper.c     15 Apr 2003 20:33:37 -0000
@@ -1123,7 +1123,6 @@
                         }
 
                         globfree(&g);
-                        g = NULL;
 #endif
                     } else {
                         /* Is there room for the entry? */



g isn't a pointer.

mrc

-- 
     Mike Castle      da...@ix...      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

Re: [Wrapper-user] Mac OS X - Segmentation Fault

[<da...@ix...>]

In article <3E9...@ta...>,
Leif Mortenson  <wra...@li...> wrote:
>I have not been able to figure out how free could be getting called more 
>than
>once for those variables.   They are being set to NULL immediately after 
>being
>freed.   Also that exact code has been working perfectly for well over a 
>year
>on all the other UNIX platforms.

WAG: Buffer overflow somewhere?  

Hmm... I was going to try ElectricFence, but that didn't get me very far.
Changing console() to do
exec df $WRAPPER_CMD ...
And core dump right away.

Running NodeWarrior Analytics Server...

  Electric Fence 2.2.0 Copyright (C) 1987-1999 Bruce Perens
<br...@pe...>

ElectricFence Aborting: Allocating 0 bytes, probably a bug.
/usr/bin/ef: line 20: 32496 Illegal instruction     (core dumped) ( export LD_PRELOAD=libefence.so.0.0; exec $* )

(gdb) bt
#0  0x42029331 in kill () from /lib/i686/libc.so.6
#1  0x4002ae98 in do_abort () from /usr/lib/libefence.so.0.0
#2  0x4002b10f in EF_Abort () from /usr/lib/libefence.so.0.0
#3  0x4002a541 in memalign () from /usr/lib/libefence.so.0.0
#4  0x4002ac26 in malloc () from /usr/lib/libefence.so.0.0
#5  0x0804b5d9 in wrapperLoadConfiguration ()
#6  0x0804c9b4 in main ()
#7  0x42017589 in __libc_start_main () from /lib/i686/libc.so.6

mrc

-- 
     Mike Castle      da...@ix...      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

[Wrapper-user] Sorry - forgot the log Re:Linux newbie - shutdown problem

[Jim E. <je...@fr...>]

I've set up my wrapper to boot/shutdown from /etc/init.d and
/etc/rc.d/rcNd using 'chkconfig:  2345 89 11' in the script and running
chkconfig --add.  Testing from the command line, the wrapper responds
correctly to service start/stop commands.  Here is the wrapper log
produced from stop issued from the command line:

INFO   | jvm 1    | 2003/04/15 07:36:33 | Received a packet 103 : ping
INFO   | jvm 1    | 2003/04/15 07:36:33 | Send a packet 103 : ok
DEBUG  | wrapperp | 2003/04/15 07:36:33 | read a packet 103 : ok
DEBUG  | wrapper  | 2003/04/15 07:36:33 | Got ping response from JVM
STATUS | wrapper  | 2003/04/15 07:36:36 | Shutting down.
DEBUG  | wrapper  | 2003/04/15 07:36:36 | wrapperStopProcess(0) called.
DEBUG  | wrapper  | 2003/04/15 07:36:36 | Sending stop signal to JVM
DEBUG  | wrapperp | 2003/04/15 07:36:36 | send a packet 101 : NULL
INFO   | jvm 1    | 2003/04/15 07:36:36 | Received a packet 101 : 
INFO   | jvm 1    | 2003/04/15 07:36:36 | Thread, Wrapper-Connection,
handling the shutdown process.
INFO   | jvm 1    | 2003/04/15 07:36:36 | calling listener.stop()
INFO   | jvm 1    | 2003/04/15 07:36:36 | WrapperSimpleApp: stop(0)
INFO   | jvm 1    | 2003/04/15 07:36:36 | returned from listener.stop()
INFO   | jvm 1    | 2003/04/15 07:36:36 | Send a packet 107 : 0
INFO   | jvm 1    | 2003/04/15 07:36:36 | Closing socket.
DEBUG  | wrapperp | 2003/04/15 07:36:36 | read a packet 107 : 0
DEBUG  | wrapper  | 2003/04/15 07:36:36 | JVM signalled that it was
stopped.
DEBUG  | wrapperp | 2003/04/15 07:36:36 | socket read no code (closed?).
INFO   | jvm 1    | 2003/04/15 07:36:36 | calling System.exit(0)
INFO   | jvm 1    | 2003/04/15 07:36:36 | 1198024 [Thread-9] INFO
<com.franklinmead.runtime.OSS.StartedService> aborting
INFO   | jvm 1    | 2003/04/15 07:36:36 | 1198024 [Thread-9] DEBUG
<com.franklinmead.runtime.OSS.StartedService> stopRequested = true
INFO   | jvm 1    | 2003/04/15 07:36:36 | 1198024 [Thread-9] DEBUG
<com.franklinmead.runtime.OSS.StartedService> internalThread interrupted
INFO   | jvm 1    | 2003/04/15 07:36:36 | 1198025 [Thread-1] INFO
<com.franklinmead.runtime.OSS.StartedService> aborting
INFO   | jvm 1    | 2003/04/15 07:36:36 | 1198025 [Thread-1] DEBUG
<com.franklinmead.runtime.OSS.StartedService> stopRequested = true
INFO   | jvm 1    | 2003/04/15 07:36:37 | 1198074 [Thread-1] DEBUG
<com.franklinmead.runtime.OSS.StartedService> internalThread interrupted
INFO   | jvm 1    | 2003/04/15 07:36:37 | 1198074 [Thread-3] INFO
<com.franklinmead.runtime.OSS.StartedService> aborting
INFO   | jvm 1    | 2003/04/15 07:36:37 | 1198074 [Thread-3] DEBUG
<com.franklinmead.runtime.OSS.StartedService> stopRequested = true
INFO   | jvm 1    | 2003/04/15 07:36:37 | 1198074 [Thread-3] DEBUG
<com.franklinmead.runtime.OSS.StartedService> internalThread interrupted
DEBUG  | wrapper  | 2003/04/15 07:36:37 | JVM exited normally.
STATUS | wrapper  | 2003/04/15 07:36:37 | <-- Wrapper Stopped


The wrapper also starts at bootime in the order I expected.  My problem
is that the wrapper appears to not respond to the stop command when I
issue shutdown -r now from the command line.  I do not receive the
"Stopping " message on the linux console, or any other message
indicating the script has received a stop command.  Instead the wrapper
thread seems to be responding to the killall issued by linux and the end
of shutdown.  Here is the wrapper log from a shutdown -r now command:

DEBUG  | wrapperp | 2003/04/15 07:51:19 | read a packet 103 : ok
DEBUG  | wrapper  | 2003/04/15 07:51:19 | Got ping response from JVM
DEBUG  | wrapperp | 2003/04/15 07:51:25 | send a packet 103 : ping
INFO   | jvm 1    | 2003/04/15 07:51:25 | Received a packet 103 : ping
INFO   | jvm 1    | 2003/04/15 07:51:25 | Send a packet 103 : ok
DEBUG  | wrapperp | 2003/04/15 07:51:25 | read a packet 103 : ok
DEBUG  | wrapper  | 2003/04/15 07:51:25 | Got ping response from JVM
STATUS | wrapper  | 2003/04/15 07:51:27 | Shutting down.
DEBUG  | wrapper  | 2003/04/15 07:51:27 | wrapperStopProcess(0) called.
DEBUG  | wrapper  | 2003/04/15 07:51:27 | Sending stop signal to JVM
DEBUG  | wrapperp | 2003/04/15 07:51:27 | send a packet 101 : NULL
INFO   | jvm 1    | 2003/04/15 07:51:27 | Processing control
event(WRAPPER_CTRL_SHUTDOWN_EVENT)
INFO   | jvm 1    | 2003/04/15 07:51:27 | WrapperSimpleApp:
controlEvent(203) Ignored


I'm not sure what I might have done wrong here.  I created my script
using the directions in the docs, but I did have to hard code the
SCRIPT_DIR and SCRIPT variables, since they assumed the script was
running from somewhere other then init.d... 

Is there some circumstance where linux will not issue the stop command
to a kill script? I have other scripts that I've set up through
chkconfig and they work fine?  Any ideas?

Jim

[Wrapper-user] Linux newbie - shutdown problem

[Jim E. <je...@fr...>]

I've set up my wrapper to boot/shutdown from /etc/init.d and
/etc/rc.d/rcNd using 'chkconfig:  2345 89 11' in the script and running
chkconfig --add.  Testing from the command line, the wrapper responds
correctly to service start/stop commands.  Here is the wrapper log
produced from stop issued from the command line:

The wrapper also starts at bootime in the order I expected.  My problem
is that the wrapper appears to not respond to the stop command when I
issue shutdown -r now from the command line.  I do not receive the
"Stopping " message on the linux console, or any other message
indicating the script has received a stop command.  Instead the wrapper
thread seems to be responding to the killall issued by linux and the end
of shutdown.  Here is the wrapper log from a shutdown -r now command:

I'm not sure what I might have done wrong here.  I created my script
using the directions in the docs, but I did have to hard code the
SCRIPT_DIR and SCRIPT variables, since they assumed the script was
running from somewhere other then init.d... 

Is there some circumstance where linux will not issue the stop command
to a kill script? I have other scripts that I've set up through
chkconfig and they work fine?  Any ideas?

Jim

Re: [Wrapper-user] Mac OS X - Segmentation Fault

[Leif M. <le...@ta...>]

Andy,
After looking over the code for about 3 hours tonight, all I can say is 
that is
very strange!!! :-/

I have not been able to figure out how free could be getting called more 
than
once for those variables.   They are being set to NULL immediately after 
being
freed.   Also that exact code has been working perfectly for well over a 
year
on all the other UNIX platforms.

I thought that I had maybe screwed up the ifdefs someplace but they all look
fine.

I went through and fixed the code in a few places where I was not setting
variables to NULL after they were freed, but none of them looked like they
could have caused any problems.  You may want to try again with these
changes but I would be surprised if they made any difference.

The OSX machine on the SF compile farm has not yet come back so I am
not able to try this out myself.  If there are any other MAC OSX users out
there who would be interested in helping out with this I would 
appreciate it.

For now I am out of ideas.  It doesn't make sense why there would be
problems like this on one UNIX platform when all other platforms are
working correctly.  But as is clearly shown in your logs below, you are
indeed having this problem :-P

As an experiment, I tried calling free twice in that code to see what 
happens
and it immediately seg faults on Linux.  So that makes me doubt that there
is a problem in the Linux version that is just hiding...

Sorry.  Not a very useful reply...

Leif :-/

Andy Barnett wrote:

> Leif,
>
> Regarding the SegFaults I was seeing, they were accompanied by this 
> cryptic console output:
>
>> Thread 0 Crashed:
>>  #0   0x9000434c in free_list_add_ptr
>>  #1   0x90003fe8 in szone_free
>>  #2   0x00004e28 in wrapperBuildJavaCommand
>>  #3   0x00003630 in wrapperEventLoop
>>  #4   0x000049e4 in wrapperRunConsole
>>  #5   0x0000591c in main
>>  #6   0x000018d8 in _start (crt.c:267)
>>  #7   0x00001758 in start
>
>
> Which I used to track down to the wrapperBuildJavaCommand function in 
> the wrapper_unix.c file. With a little trial & error, I ended up 
> making this change to that function (note my 2 new printf's):
>
>>   while(wrapperData->jvmCommand[i] != NULL) {
>>     printf("before free [%d]\n", i);
>>     free(wrapperData->jvmCommand[i]);
>>     printf("after free [%d]\n", i);
>>     wrapperData->jvmCommand[i] = NULL;
>>     i++;
>>   }
>
>
> Then when I executed "cd bin; ./testwrapper console", I saw this output:
>
>> wrapper  | --> Wrapper Started as Console
>> wrapper  | Launching a JVM...
>> jvm 1    | Initializing...
>> jvm 1    | Wrapper (Version 3.0.3)
>> jvm 1    |
>> jvm 1    | start()
>> wrapper  | JVM exited unexpectedly.
>> before free [0]
>> after free [0]
>> before free [1]
>> after free [1]
>> before free [2]
>> after free [2]
>> before free [3]
>> after free [3]
>> before free [4]
>> after free [4]
>> before free [5]
>> after free [5]
>> before free [6]
>> after free [6]
>> before free [7]
>> after free [7]
>> before free [8]
>> after free [8]
>> before free [9]
>> after free [9]
>> before free [10]
>> after free [10]
>> before free [11]
>> *** malloc[1553]: Deallocation of a pointer not malloced: 0xc000; 
>> This could be a double free(), or free() called with the middle of an 
>> allocated block; Try setting environment variable MallocHelp to see 
>> tools to help debug
>> after free [11]
>> before free [12]
>> *** malloc[1553]: Deallocation of a pointer not malloced: 0x357b; 
>> This could be a double free(), or free() called with the middle of an 
>> allocated block; Try setting environment variable MallocHelp to see 
>> tools to help debug
>> after free [12]
>> wrapper  | Launching a JVM...
>> jvm 2    | Initializing...
>> jvm 2    | Wrapper (Version 3.0.3)
>> jvm 2    |
>> jvm 2    | start()
>> jvm 2    | stop(0)
>> wrapper  | <-- Wrapper Stopped
>
>
> Note: the first "JVM exited unexpectedly" was due to clicking the 
> "halt(0)" button in the GUI, and the final "stop(0)" was due to 
> clicking the "exit" button.
>
> So it appears that the last two indexed values in the jvmCommand, 
> while not NULL, are already freed once and this code is free'ing a 2nd 
> time.
>
> What are your thoughts on this?
> ~Andy
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

Re: [Wrapper-user] 2 issues...

[David O. J. <da...@da...>]

On Tuesday, April 15, 2003 8:40 AM,
Leif Mortenson <le...@ta...> wrote:

> Jan,
>
>> Java Service Wrapper is really brilliant software! (Will for sure
>> donate if we make money :-)
>
> Thanks we would appreciate that. :-)
>
>> It took me 4 hours to implement it with my server, but sadly I did
>> spend 3 hours searching for a bug which is in the docs
>>
http://wrapper.tanukisoftware.org/doc/english/integrate-start-stop-win.html
>> on this page "wrapper.app.parameter.4" is missing in all samples which
>> causes the service fail to start ! (it stops processing after parameter
3)
>
> Sorry about that...  Not sure how I missed that, but thanks for
> reporting it.  I've
> got it fixed in CVS and will get the web site updated.  The release docs
> will be
> updated in the next release.
>

Silly me.  I hadn't tried this, but saw it in the docs (in the Linux
materials) and thought this was done on purpose.  Man that would have bit me
hard when I went to implement it...

Oh well, thank goodness for this list... :)

--
David Orriss Jr.

Please email me if you want my ICQ/AIM/IM ID's.

Re: [Wrapper-user] 2 issues...

[Leif M. <le...@ta...>]

Jan,

> Java Service Wrapper is really brilliant software! (Will for sure 
> donate if we make money :-)

Thanks we would appreciate that. :-)

> It took me 4 hours to implement it with my server, but sadly I did 
> spend 3 hours searching for a bug which is in the docs
> http://wrapper.tanukisoftware.org/doc/english/integrate-start-stop-win.html
> on this page "wrapper.app.parameter.4" is missing in all samples which 
> causes the service fail to start ! (it stops processing after parameter 3)

Sorry about that...  Not sure how I missed that, but thanks for 
reporting it.  I've
got it fixed in CVS and will get the web site updated.  The release docs 
will be
updated in the next release.

>  I also noticed that placing quotes is not handled transparently:
> OK:wrapper.java.library.path.1=C:\Program Files\Servoy\service
> BAD:wrapper.java.library.path.1="C:\Program Files\Servoy\service"

I need to add some checks to make sure that the user never quotes this
property.  In your example, it is simple, but when there are multiple 
library
path entries, the entire library path needs to be quoted.  Having the
individual elements quoted will not work.   The Wrapper builds up the entire
path and then wraps the whole thing in quotes to make things work correctly
with paths containing spaces.  This is also an issue with the classpath
properties.
I added a note to the docs for both properties to make this usage a little
more clear.

> OK:wrapper.java.additional.1=-Duser.dir="C:\Program Files\Servoy"
> BAD:wrapper.java.additional.1=-Duser.dir=C:\Program Files\Servoy

This is described in the docs for this property.  I need to add a check
to make sure that the Wrapper warns the user if they specify a java
additional property that contains unquoted spaces.  You will have the
same issue with the app parameter properties.

I am always looking to improve the documentation.  So please let me
know if you find any other areas that are confusing.

Cheers,
Leif

[Wrapper-user] 2 issues...

[Jan B. <jb...@pr...>]

Hi,
 
Java Service Wrapper is really brilliant software! (Will for sure donate
if we make money :-)
 
It took me 4 hours to implement it with my server, but sadly I did spend
3 hours searching for a bug which is in the docs
http://wrapper.tanukisoftware.org/doc/english/integrate-start-stop-win.h
tml
on this page "wrapper.app.parameter.4" is missing in all samples which
causes the service fail to start ! (it stops processing after parameter
3)
 
I also noticed that placing quotes is not handled transparently:

OK:wrapper.java.library.path.1=C:\Program Files\Servoy\service
BAD:wrapper.java.library.path.1="C:\Program Files\Servoy\service"
 
OK:wrapper.java.additional.1=-Duser.dir="C:\Program Files\Servoy"

BAD:wrapper.java.additional.1=-Duser.dir=C:\Program Files\Servoy
 
This made me puzzled as well, the best thing would be to detect if
quotes are present and don't place quotes again. (that is what happens
en causes errors)


Kind Regards
Jan Blok

Re: [Wrapper-user] Regarding Windows NT service

[Leif M. <le...@ta...>]

Ravi,
    I am guessing that your printer is a network printer.  By default, a 
service is
run as the SYSTEM user.  You can see this by looking at the Task Manager.
The problem is that the SYSTEM user does not have all of the network
associations as the user running the application as a service.
    To fix this, you need to configure the Wrapper to run as a specific 
user.
See the wrapper.ntservice.account and wrapper.ntservice.password
properties for details.  Be sure to read their docs for further details.

Cheers,
Leif


Ravi Shankar wrote:

> Hi Leif,
>  How are you ? Hope everything is fine and we are happy with NT 
> service wrapper. However some days back I had  noticed a problem: When 
> we run our reporting tool as a service and start it up, then we are 
> not able to do network printing. We removed the servive and started 
> manually, then we could do the printing. Please enlight us with your 
> valuable advice, thanks
>  
> Thanks and regards,
> Ravi

[Wrapper-user] Regarding Windows NT service

[Ravi S. <ra...@el...>]

Hi Leif,
 How are you ? Hope everything is fine and we are happy with NT service =
wrapper. However some days back I had  noticed a problem: When we run =
our reporting tool as a service and start it up, then we are not able to =
do network printing. We removed the servive and started manually, then =
we could do the printing. Please enlight us with your valuable advice, =
thanks

Thanks and regards,
Ravi

[Wrapper-user] Mac OS X - Segmentation Fault

[Andy B. <aba...@ca...>]

Leif,

Regarding the SegFaults I was seeing, they were accompanied by this 
cryptic console output:

> Thread 0 Crashed:
>  #0   0x9000434c in free_list_add_ptr
>  #1   0x90003fe8 in szone_free
>  #2   0x00004e28 in wrapperBuildJavaCommand
>  #3   0x00003630 in wrapperEventLoop
>  #4   0x000049e4 in wrapperRunConsole
>  #5   0x0000591c in main
>  #6   0x000018d8 in _start (crt.c:267)
>  #7   0x00001758 in start

Which I used to track down to the wrapperBuildJavaCommand function in 
the wrapper_unix.c file. With a little trial & error, I ended up making 
this change to that function (note my 2 new printf's):

>   while(wrapperData->jvmCommand[i] != NULL) {
>     printf("before free [%d]\n", i);
>     free(wrapperData->jvmCommand[i]);
>     printf("after free [%d]\n", i);
>     wrapperData->jvmCommand[i] = NULL;
>     i++;
>   }

Then when I executed "cd bin; ./testwrapper console", I saw this output:

> wrapper  | --> Wrapper Started as Console
> wrapper  | Launching a JVM...
> jvm 1    | Initializing...
> jvm 1    | Wrapper (Version 3.0.3)
> jvm 1    |
> jvm 1    | start()
> wrapper  | JVM exited unexpectedly.
> before free [0]
> after free [0]
> before free [1]
> after free [1]
> before free [2]
> after free [2]
> before free [3]
> after free [3]
> before free [4]
> after free [4]
> before free [5]
> after free [5]
> before free [6]
> after free [6]
> before free [7]
> after free [7]
> before free [8]
> after free [8]
> before free [9]
> after free [9]
> before free [10]
> after free [10]
> before free [11]
> *** malloc[1553]: Deallocation of a pointer not malloced: 0xc000; This 
> could be a double free(), or free() called with the middle of an 
> allocated block; Try setting environment variable MallocHelp to see 
> tools to help debug
> after free [11]
> before free [12]
> *** malloc[1553]: Deallocation of a pointer not malloced: 0x357b; This 
> could be a double free(), or free() called with the middle of an 
> allocated block; Try setting environment variable MallocHelp to see 
> tools to help debug
> after free [12]
> wrapper  | Launching a JVM...
> jvm 2    | Initializing...
> jvm 2    | Wrapper (Version 3.0.3)
> jvm 2    |
> jvm 2    | start()
> jvm 2    | stop(0)
> wrapper  | <-- Wrapper Stopped

Note: the first "JVM exited unexpectedly" was due to clicking the 
"halt(0)" button in the GUI, and the final "stop(0)" was due to 
clicking the "exit" button.

So it appears that the last two indexed values in the jvmCommand, while 
not NULL, are already freed once and this code is free'ing a 2nd time.

What are your thoughts on this?
~Andy

[Wrapper-user] Re: [PATCH] Support for Mac OS X

[Leif M. <le...@ta...>]

Andy,
    I got the patch that you supplied committed, but when I went up to the
Sourceforge compile farm to test it out, I found that the OSX host is not
currently available.  Not sure if it is down or gone.  I will have to 
check back
later.
    Are you still having the crash problems that you had mentioned before?
Those will need to get fixed before I can do a release with OSX support.
If the SourceForge OSX host comes back online, I will take a look at it.
Otherwise my hands are tied.  If you do a build with DEBUG enabled the
generated binary will kick out a large amount of output as the server is
being started up.  That might provide some clues as to where the crash
you were seeing is originating.   Otherwise, I always use the low tech
"printf" method of tracking these things down. :-/

You should be able to enable debug output with the following change in
your makefile :
COMPILE = gcc -O3 -Wall -pedantic -D_DEBUG

Cheers,
Leif

Andy Barnett wrote:

> See attached gzip'd tar file containing "patchfile.txt" created with 
> "cvs diff -u" using the latest code from CVS, plus the new 
> "Makefile.macosx" file.
>
> ~Andy
>
>
>
> On Sunday, April 13, 2003, at 09:48  PM, Leif Mortenson wrote:
>
>> Andy,
>>    Go ahead and send the files to me directly.  I'll take a look at 
>> them and try
>> to getting it running on the MasOSX machine running on the SF compile
>> farm.   If I have any Questions I may ask you to try running a test 
>> build for me
>> or something.
>>
>> Cheers,
>> Leif
>>
>> Andy Barnett wrote:
>>
>>> Would you like me to post the patched files to this mailing list or 
>>> to  the Patches section of wrapper.sourceforge.net? Also, is a "cvs 
>>> diff  -u" patchfile sufficient?
>>>
>>> FYI, I still need to put in IFDEFs in the C code to mark my Mac  
>>> changes. I know a lot more Java than I know C, so I'm going to use 
>>> the  advice in this message as my guide for Mac OS X IFDEFs.
>>>      <http://www.omnigroup.com/mailman/archive/macosx-dev/2000-May/ 
>>> 001923.html>
>>>
>>> One last note, I get Segmentation Faults when  
>>> "wrapper.logfile.loglevel" is set to INFO. I found that setting this 
>>> to  DEBUG made the Segmentation Faults go away. Perhaps this points 
>>> to a  bug somewhere. I'll try to reproduce this problem again and 
>>> post the  console output of the SegFault; I've done zero C coding on 
>>> Macs so the  error output didn't help me much.
>>>
>>> Cheers,
>>> ~Andy
>>

Re: [Wrapper-user] Support for Mac OS X

[Leif M. <le...@ta...>]

Andy,
    Go ahead and send the files to me directly.  I'll take a look at 
them and try
to getting it running on the MasOSX machine running on the SF compile
farm.   If I have any Questions I may ask you to try running a test 
build for me
or something.

Cheers,
Leif

Andy Barnett wrote:

> Would you like me to post the patched files to this mailing list or 
> to  the Patches section of wrapper.sourceforge.net? Also, is a "cvs 
> diff  -u" patchfile sufficient?
>
> FYI, I still need to put in IFDEFs in the C code to mark my Mac  
> changes. I know a lot more Java than I know C, so I'm going to use 
> the  advice in this message as my guide for Mac OS X IFDEFs.
>      <http://www.omnigroup.com/mailman/archive/macosx-dev/2000-May/ 
> 001923.html>
>
> One last note, I get Segmentation Faults when  
> "wrapper.logfile.loglevel" is set to INFO. I found that setting this 
> to  DEBUG made the Segmentation Faults go away. Perhaps this points to 
> a  bug somewhere. I'll try to reproduce this problem again and post 
> the  console output of the SegFault; I've done zero C coding on Macs 
> so the  error output didn't help me much.
>
> Cheers,
> ~Andy
>
> On Sunday, April 13, 2003, at 12:22  AM, Leif Mortenson wrote:
>
>> Great that was on my list.  There is even a MacOSX server on the
>> SourceForge compile farm so I can start including it in releases.   
>> Please
>> post the patched files.  CVS diffs if possible.  I can handle the  
>> source files
>> as is though if need be.
>>
>> Cheers,
>> Leif
>>
>> Andy Barnett wrote:
>>
>>> Has any effort been put toward making Java Service Wrapper 
>>> compatible  with Mac OS X? I could not find any references to Mac OS 
>>> X in the  forums or mailing lists.
>>>
>>> If anyone is interested I have successfully compiled and executed  
>>> Java Service Wrapper on my iMac -- more specifically: Mac OS X  
>>> (Version 10.2.5) with Java 2 (1.4.1_01) and Apple's version of gcc3  
>>> and gmake.
>>>
>>> I had to create a new Makefile.macosx, extend build.xml to 
>>> recognize  Mac OS X, and tweak property.c, wrapper.c, and wrapper.h.
>>>
>>> Cheers,
>>> ~Andy
>>> aba...@ca...
>>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The 
> debugger for complex code. Debugging C/C++ programs can leave you 
> feeling lost and disoriented. TotalView can help you find your way. 
> Available on major UNIX and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

Re: [Wrapper-user] Support for Mac OS X

[Andy B. <aba...@ca...>]

Would you like me to post the patched files to this mailing list or to  
the Patches section of wrapper.sourceforge.net? Also, is a "cvs diff  
-u" patchfile sufficient?

FYI, I still need to put in IFDEFs in the C code to mark my Mac  
changes. I know a lot more Java than I know C, so I'm going to use the  
advice in this message as my guide for Mac OS X IFDEFs.
      
<http://www.omnigroup.com/mailman/archive/macosx-dev/2000-May/ 
001923.html>

One last note, I get Segmentation Faults when  
"wrapper.logfile.loglevel" is set to INFO. I found that setting this to  
DEBUG made the Segmentation Faults go away. Perhaps this points to a  
bug somewhere. I'll try to reproduce this problem again and post the  
console output of the SegFault; I've done zero C coding on Macs so the  
error output didn't help me much.

Cheers,
~Andy

On Sunday, April 13, 2003, at 12:22  AM, Leif Mortenson wrote:

> Great that was on my list.  There is even a MacOSX server on the
> SourceForge compile farm so I can start including it in releases.   
> Please
> post the patched files.  CVS diffs if possible.  I can handle the  
> source files
> as is though if need be.
>
> Cheers,
> Leif
>
> Andy Barnett wrote:
>
>> Has any effort been put toward making Java Service Wrapper compatible  
>> with Mac OS X? I could not find any references to Mac OS X in the  
>> forums or mailing lists.
>>
>> If anyone is interested I have successfully compiled and executed  
>> Java Service Wrapper on my iMac -- more specifically: Mac OS X  
>> (Version 10.2.5) with Java 2 (1.4.1_01) and Apple's version of gcc3  
>> and gmake.
>>
>> I had to create a new Makefile.macosx, extend build.xml to recognize  
>> Mac OS X, and tweak property.c, wrapper.c, and wrapper.h.
>>
>> Cheers,
>> ~Andy
>> aba...@ca...

Re: [Wrapper-user] Support for Mac OS X

[Leif M. <le...@ta...>]

Great that was on my list.  There is even a MacOSX server on the
SourceForge compile farm so I can start including it in releases.  Please
post the patched files.  CVS diffs if possible.  I can handle the source 
files
as is though if need be.

Cheers,
Leif

Andy Barnett wrote:

> Has any effort been put toward making Java Service Wrapper compatible 
> with Mac OS X? I could not find any references to Mac OS X in the 
> forums or mailing lists.
>
> If anyone is interested I have successfully compiled and executed Java 
> Service Wrapper on my iMac -- more specifically: Mac OS X (Version 
> 10.2.5) with Java 2 (1.4.1_01) and Apple's version of gcc3 and gmake.
>
> I had to create a new Makefile.macosx, extend build.xml to recognize 
> Mac OS X, and tweak property.c, wrapper.c, and wrapper.h.
>
> Cheers,
> ~Andy
> aba...@ca...
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The 
> debugger for complex code. Debugging C/C++ programs can leave you 
> feeling lost and disoriented. TotalView can help you find your way. 
> Available on major UNIX and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

[Wrapper-user] Support for Mac OS X

[Andy B. <aba...@ca...>]

Has any effort been put toward making Java Service Wrapper compatible 
with Mac OS X? I could not find any references to Mac OS X in the 
forums or mailing lists.

If anyone is interested I have successfully compiled and executed Java 
Service Wrapper on my iMac -- more specifically: Mac OS X (Version 
10.2.5) with Java 2 (1.4.1_01) and Apple's version of gcc3 and gmake.

I had to create a new Makefile.macosx, extend build.xml to recognize 
Mac OS X, and tweak property.c, wrapper.c, and wrapper.h.

Cheers,
~Andy
aba...@ca...

Re: [Wrapper-user] Shutdown hook not called

[Leif M. <le...@ta...>]

Richard,
    Sorry. It looks like I somehow missed your post on 3/29.

Richard Emberson wrote:

>On windows I get the following message in the wrapper log after I request the
>wrapper as a windows service to be stopped.
>
>ERROR | wrapper |  <date> |  JVM exited unexpectedly while stopping the
>application.
>
>The call I make to stop the wrapper as a service is (for example):
>
>net stop "My Service Name"
>
    From what you posted, I can't give you an exact cause.  Could you please
enable debug logging to the file and then post the resulting log file of 
a single
run on your application.  That should give me the clues that I need to 
give you
an answer.

>The problem is that my Java program has a Shutdown hook and it is NOT being
>called.
>How do I stop the wrapper service so that Shutdown hooks execute?
>
That would be strange.  I assume you are using at least Java 1.3, 
otherwise you
would ot be able to register your shutdown hook in the first place.  The 
above
debug log output may give me further clues.

In your other mail, you also mentioned a "Shutdown complete" message
sometimes showing up in your wrapper.log and sometimes in the log4j
log file.  Is that a message from your application?  I'll take a look a look
at the log when you send it and see if I have any ideas here as well.

Cheers,
Leif

[Wrapper-user] Shutdown hook not called

[Richard E. <rem...@ou...>]

On windows I get the following message in the wrapper log after I request the
wrapper as a windows service to be stopped.

ERROR | wrapper |  <date> |  JVM exited unexpectedly while stopping the
application.

The call I make to stop the wrapper as a service is (for example):

net stop "My Service Name"

The problem is that my Java program has a Shutdown hook and it is NOT being
called.
How do I stop the wrapper service so that Shutdown hooks execute?

Thanks.

Richard

Re: [Wrapper-user] JSW 3.0.2

[Leif M. <le...@ta...>]

Stefan,
    I need to add some checks to make sure that the Wrapper.exe, Wrapper.DLL
and wrapper.jar file are all the same version.  The problem here is that 
your
Wrapper.exe is version 3.0.2 but your wrapper.jar is version 3.0.1
The protocol between the two changed slightly.  Your application should 
still be
working correctly other than the warning message below.  Let me know if 
it is
not.

Cheers,
Leif

Pauwels Stefan wrote:

>I tested out version 3.0.2 of the service wrapper
>
<snip>

>INFO   | jvm 1    | 2003/04/10 09:48:39 | Wrapper (Version 3.0.1)
>  
>