You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4cxx-user@logging.apache.org by Dale King <da...@gmail.com> on 2008/03/06 23:27:42 UTC

2 issues found with 0.10.0-RC2

I built using visual studio and ran into a couple of problems to report.

OdbcAppender  has unicode issues. There are 3 calls to SQL
(SQLExecDirect, SQLDiagRec, and SQLDriverConnect) where the paramters
are based on SQLCHAR. This doesn't work when building for Unicode as
these functions really call the wide character version. Thes calls
should have an A appended to the name to call the non unicode version.
In reality this file should probably be made to work either way.

I used a properties file and configured a ConsoleAppender but did not
set the layout for it. Instead of nicely handling it, it crashed the
application. Probably should fail more gracefully.

-- 
Dale King

Re: 2 issues found with 0.10.0-RC2

Posted by Dale King <da...@gmail.com>.
Yes, I think it is a further symptom of what happens when it receives
a connection while in that hung state. Here is the stack trace os when
it crashes:

 	libapr-1.dll!_apr_pool_destroy@4()  + 0xc bytes	
 	[Frames below may be incorrect and/or missing, no symbols loaded for
libapr-1.dll]
 	libapr-1.dll!_apr_thread_exit@8()  + 0x15 bytes	
>	testLog4Cxx.exe!log4cxx::helpers::Thread::launcher(void *
thread=0x00d82150, void * data=0x00d82140)  Line 102 + 0xe bytes	C++
 	libapr-1.dll!_apr_thread_create@20()  + 0xe0 bytes	
 	msvcrt.dll!_endthreadex()  + 0xa9 bytes	
 	kernel32.dll!GetModuleFileNameA()  + 0x1b4 bytes	


On Sat, Mar 8, 2008 at 5:48 PM, Ufuk Kayserilioglu <gr...@paralaus.com> wrote:
> Hello Dale,
>
>  Please have a look at the bug I filed on JIRA [1] about the problem that
>  we ran into about the TelnetAppender and see if the fix there solves
>  your problem.
>
>   From your description, I have a feeling that the same thing is biting you.
>
>  Ufuk Kayserilioglu
>
>  [1] https://issues.apache.org/jira/browse/LOGCXX-246
>
>
>
>  Dale King wrote:
>  > It failed at compile time.
>  >
>  > For windows at least with unicode these names are actually #defines of the form:
>  >
>  > #define SQLExecDirect SQLExecDirectW
>  >
>  > I was trying to find some way with a #if to ask the question like:
>  >
>  > #if SQLExecDirect == "SQLExecDirectW"
>  >
>  > but there doesn't seem to be a way to do a conditional off of what
>  > text is in a define.
>  >
>  > I found another issue.
>  >
>  > Started app with a TelnetAdapter, connected to it, closed connection,
>  > reconfigure (automatically based on watchdog on the xml file), connect
>  > again, app crashes. Seems to be very repeatable following those steps.
>  >
>  > On Sat, Mar 8, 2008 at 1:03 PM, Curt Arnold <ca...@apache.org> wrote:
>  >
>  >>  On Mar 6, 2008, at 4:27 PM, Dale King wrote:
>  >>
>  >>  > I built using visual studio and ran into a couple of problems to
>  >>  > report.
>  >>  >
>  >>  > OdbcAppender  has unicode issues. There are 3 calls to SQL
>  >>  > (SQLExecDirect, SQLDiagRec, and SQLDriverConnect) where the paramters
>  >>  > are based on SQLCHAR. This doesn't work when building for Unicode as
>  >>  > these functions really call the wide character version. Thes calls
>  >>  > should have an A appended to the name to call the non unicode version.
>  >>  > In reality this file should probably be made to work either way.
>  >>  >
>  >>  > I used a properties file and configured a ConsoleAppender but did not
>  >>  > set the layout for it. Instead of nicely handling it, it crashed the
>  >>  > application. Probably should fail more gracefully.
>  >>  >
>  >>  > --
>  >>  > Dale King
>  >>
>  >>  Filed these as LOGCXX-248 and 249.  Will have to dig into the
>  >>  ODBCAppender since that is also supported on Linux (using iODBC or
>  >>  unixODBC) and just appending an "A" for the char-based API won't cover
>  >>  that case.  How did it fail, at compile time or run time?
>  >>
>  >>
>  >
>  >
>  >
>  >
>
>
>



-- 
Dale King

Re: 2 issues found with 0.10.0-RC2

Posted by Ufuk Kayserilioglu <gr...@paralaus.com>.
I am glad to see independent confirmation. Thank you.

Now we are waiting for the fix to be checked into the repository. :)

Ufuk Kayserilioglu

Dale King wrote:
> It does fix the problem by the way.
>
> On Sat, Mar 8, 2008 at 5:48 PM, Ufuk Kayserilioglu <gr...@paralaus.com> wrote:
>   
>> Hello Dale,
>>
>>  Please have a look at the bug I filed on JIRA [1] about the problem that
>>  we ran into about the TelnetAppender and see if the fix there solves
>>  your problem.
>>
>>   From your description, I have a feeling that the same thing is biting you.
>>
>>  Ufuk Kayserilioglu
>>
>>  [1] https://issues.apache.org/jira/browse/LOGCXX-246
>>
>>
>>
>>  Dale King wrote:
>>  > It failed at compile time.
>>  >
>>  > For windows at least with unicode these names are actually #defines of the form:
>>  >
>>  > #define SQLExecDirect SQLExecDirectW
>>  >
>>  > I was trying to find some way with a #if to ask the question like:
>>  >
>>  > #if SQLExecDirect == "SQLExecDirectW"
>>  >
>>  > but there doesn't seem to be a way to do a conditional off of what
>>  > text is in a define.
>>  >
>>  > I found another issue.
>>  >
>>  > Started app with a TelnetAdapter, connected to it, closed connection,
>>  > reconfigure (automatically based on watchdog on the xml file), connect
>>  > again, app crashes. Seems to be very repeatable following those steps.
>>  >
>>  > On Sat, Mar 8, 2008 at 1:03 PM, Curt Arnold <ca...@apache.org> wrote:
>>  >
>>  >>  On Mar 6, 2008, at 4:27 PM, Dale King wrote:
>>  >>
>>  >>  > I built using visual studio and ran into a couple of problems to
>>  >>  > report.
>>  >>  >
>>  >>  > OdbcAppender  has unicode issues. There are 3 calls to SQL
>>  >>  > (SQLExecDirect, SQLDiagRec, and SQLDriverConnect) where the paramters
>>  >>  > are based on SQLCHAR. This doesn't work when building for Unicode as
>>  >>  > these functions really call the wide character version. Thes calls
>>  >>  > should have an A appended to the name to call the non unicode version.
>>  >>  > In reality this file should probably be made to work either way.
>>  >>  >
>>  >>  > I used a properties file and configured a ConsoleAppender but did not
>>  >>  > set the layout for it. Instead of nicely handling it, it crashed the
>>  >>  > application. Probably should fail more gracefully.
>>  >>  >
>>  >>  > --
>>  >>  > Dale King
>>  >>
>>  >>  Filed these as LOGCXX-248 and 249.  Will have to dig into the
>>  >>  ODBCAppender since that is also supported on Linux (using iODBC or
>>  >>  unixODBC) and just appending an "A" for the char-based API won't cover
>>  >>  that case.  How did it fail, at compile time or run time?
>>  >>
>>  >>
>>  >
>>  >
>>  >
>>  >
>>
>>
>>
>>     
>
>
>
>   



Re: 2 issues found with 0.10.0-RC2

Posted by Dale King <da...@gmail.com>.
It does fix the problem by the way.

On Sat, Mar 8, 2008 at 5:48 PM, Ufuk Kayserilioglu <gr...@paralaus.com> wrote:
> Hello Dale,
>
>  Please have a look at the bug I filed on JIRA [1] about the problem that
>  we ran into about the TelnetAppender and see if the fix there solves
>  your problem.
>
>   From your description, I have a feeling that the same thing is biting you.
>
>  Ufuk Kayserilioglu
>
>  [1] https://issues.apache.org/jira/browse/LOGCXX-246
>
>
>
>  Dale King wrote:
>  > It failed at compile time.
>  >
>  > For windows at least with unicode these names are actually #defines of the form:
>  >
>  > #define SQLExecDirect SQLExecDirectW
>  >
>  > I was trying to find some way with a #if to ask the question like:
>  >
>  > #if SQLExecDirect == "SQLExecDirectW"
>  >
>  > but there doesn't seem to be a way to do a conditional off of what
>  > text is in a define.
>  >
>  > I found another issue.
>  >
>  > Started app with a TelnetAdapter, connected to it, closed connection,
>  > reconfigure (automatically based on watchdog on the xml file), connect
>  > again, app crashes. Seems to be very repeatable following those steps.
>  >
>  > On Sat, Mar 8, 2008 at 1:03 PM, Curt Arnold <ca...@apache.org> wrote:
>  >
>  >>  On Mar 6, 2008, at 4:27 PM, Dale King wrote:
>  >>
>  >>  > I built using visual studio and ran into a couple of problems to
>  >>  > report.
>  >>  >
>  >>  > OdbcAppender  has unicode issues. There are 3 calls to SQL
>  >>  > (SQLExecDirect, SQLDiagRec, and SQLDriverConnect) where the paramters
>  >>  > are based on SQLCHAR. This doesn't work when building for Unicode as
>  >>  > these functions really call the wide character version. Thes calls
>  >>  > should have an A appended to the name to call the non unicode version.
>  >>  > In reality this file should probably be made to work either way.
>  >>  >
>  >>  > I used a properties file and configured a ConsoleAppender but did not
>  >>  > set the layout for it. Instead of nicely handling it, it crashed the
>  >>  > application. Probably should fail more gracefully.
>  >>  >
>  >>  > --
>  >>  > Dale King
>  >>
>  >>  Filed these as LOGCXX-248 and 249.  Will have to dig into the
>  >>  ODBCAppender since that is also supported on Linux (using iODBC or
>  >>  unixODBC) and just appending an "A" for the char-based API won't cover
>  >>  that case.  How did it fail, at compile time or run time?
>  >>
>  >>
>  >
>  >
>  >
>  >
>
>
>



-- 
Dale King

Re: 2 issues found with 0.10.0-RC2

Posted by Ufuk Kayserilioglu <gr...@paralaus.com>.
Hello Dale,

Please have a look at the bug I filed on JIRA [1] about the problem that 
we ran into about the TelnetAppender and see if the fix there solves 
your problem.

 From your description, I have a feeling that the same thing is biting you.

Ufuk Kayserilioglu

[1] https://issues.apache.org/jira/browse/LOGCXX-246

Dale King wrote:
> It failed at compile time.
>
> For windows at least with unicode these names are actually #defines of the form:
>
> #define SQLExecDirect SQLExecDirectW
>
> I was trying to find some way with a #if to ask the question like:
>
> #if SQLExecDirect == "SQLExecDirectW"
>
> but there doesn't seem to be a way to do a conditional off of what
> text is in a define.
>
> I found another issue.
>
> Started app with a TelnetAdapter, connected to it, closed connection,
> reconfigure (automatically based on watchdog on the xml file), connect
> again, app crashes. Seems to be very repeatable following those steps.
>
> On Sat, Mar 8, 2008 at 1:03 PM, Curt Arnold <ca...@apache.org> wrote:
>   
>>  On Mar 6, 2008, at 4:27 PM, Dale King wrote:
>>
>>  > I built using visual studio and ran into a couple of problems to
>>  > report.
>>  >
>>  > OdbcAppender  has unicode issues. There are 3 calls to SQL
>>  > (SQLExecDirect, SQLDiagRec, and SQLDriverConnect) where the paramters
>>  > are based on SQLCHAR. This doesn't work when building for Unicode as
>>  > these functions really call the wide character version. Thes calls
>>  > should have an A appended to the name to call the non unicode version.
>>  > In reality this file should probably be made to work either way.
>>  >
>>  > I used a properties file and configured a ConsoleAppender but did not
>>  > set the layout for it. Instead of nicely handling it, it crashed the
>>  > application. Probably should fail more gracefully.
>>  >
>>  > --
>>  > Dale King
>>
>>  Filed these as LOGCXX-248 and 249.  Will have to dig into the
>>  ODBCAppender since that is also supported on Linux (using iODBC or
>>  unixODBC) and just appending an "A" for the char-based API won't cover
>>  that case.  How did it fail, at compile time or run time?
>>
>>     
>
>
>
>   



Re: 2 issues found with 0.10.0-RC2

Posted by Dale King <da...@gmail.com>.
It failed at compile time.

For windows at least with unicode these names are actually #defines of the form:

#define SQLExecDirect SQLExecDirectW

I was trying to find some way with a #if to ask the question like:

#if SQLExecDirect == "SQLExecDirectW"

but there doesn't seem to be a way to do a conditional off of what
text is in a define.

I found another issue.

Started app with a TelnetAdapter, connected to it, closed connection,
reconfigure (automatically based on watchdog on the xml file), connect
again, app crashes. Seems to be very repeatable following those steps.

On Sat, Mar 8, 2008 at 1:03 PM, Curt Arnold <ca...@apache.org> wrote:
>
>
>  On Mar 6, 2008, at 4:27 PM, Dale King wrote:
>
>  > I built using visual studio and ran into a couple of problems to
>  > report.
>  >
>  > OdbcAppender  has unicode issues. There are 3 calls to SQL
>  > (SQLExecDirect, SQLDiagRec, and SQLDriverConnect) where the paramters
>  > are based on SQLCHAR. This doesn't work when building for Unicode as
>  > these functions really call the wide character version. Thes calls
>  > should have an A appended to the name to call the non unicode version.
>  > In reality this file should probably be made to work either way.
>  >
>  > I used a properties file and configured a ConsoleAppender but did not
>  > set the layout for it. Instead of nicely handling it, it crashed the
>  > application. Probably should fail more gracefully.
>  >
>  > --
>  > Dale King
>
>  Filed these as LOGCXX-248 and 249.  Will have to dig into the
>  ODBCAppender since that is also supported on Linux (using iODBC or
>  unixODBC) and just appending an "A" for the char-based API won't cover
>  that case.  How did it fail, at compile time or run time?
>



-- 
Dale King

Re: 2 issues found with 0.10.0-RC2

Posted by Curt Arnold <ca...@apache.org>.
On Mar 6, 2008, at 4:27 PM, Dale King wrote:

> I built using visual studio and ran into a couple of problems to  
> report.
>
> OdbcAppender  has unicode issues. There are 3 calls to SQL
> (SQLExecDirect, SQLDiagRec, and SQLDriverConnect) where the paramters
> are based on SQLCHAR. This doesn't work when building for Unicode as
> these functions really call the wide character version. Thes calls
> should have an A appended to the name to call the non unicode version.
> In reality this file should probably be made to work either way.
>
> I used a properties file and configured a ConsoleAppender but did not
> set the layout for it. Instead of nicely handling it, it crashed the
> application. Probably should fail more gracefully.
>
> -- 
> Dale King

Filed these as LOGCXX-248 and 249.  Will have to dig into the  
ODBCAppender since that is also supported on Linux (using iODBC or  
unixODBC) and just appending an "A" for the char-based API won't cover  
that case.  How did it fail, at compile time or run time?