cppcms-users — Disussions of users of CppCMS

Re: [Cppcms-users] SIGABRT problem raised between SVN rev1474 and 1491

[Artyom <art...@ya...>]

 
> Hallo,
> 
> I see your point and will try to provide a  sample tomorrow. I 
> nevertheless think that it must have at least something  to do with your 
> changes between the two revisions mentioned, because with  the same code 
> on my side (of course, recompiled for the revision to be  tested) with 
> the earlier revision everything works smooth while it doesn't  with the 
> latter revision.
> Couldn't the invalid write mentioned in  valgrind's outputs lead to the 
> SIGABRT?


> What I don't understand anyway  is
> 1. Why does the SIGABRT occur when running without any debugger attached 
> or with gdb, but not with valgrind?

AFAIK valgrind replaces some basic functions like malloc for better control
of output.

> The program runs (besides of the 
> 2. Why, at all, is it a SIGABRT and not a SIGSEGV? According to  the 
> output it is a memory access violation and should be a SIGSEGV then, I 
> think.

Because it is rather heap structure corruption rather 
then memory access violation. So libc detects the issue and aborts the
program before it is "too late"

> 
> Could it be that you changed the implementation of  bad_value_cast so 
> that an instantiation like this is not possible  anymore?

Shouldn't be, in any case you may try following:

Comment out lines: 13 and 14 in file:  booster/lib/backtrace/src/backtrace.cpp

Such it would be

#if defined(__linux) || defined(__APPLE__) || defined(__sun)
//#define BOOSTER_HAVE_EXECINFO
//#define BOOSTER_HAVE_DLADDR
#endif

And tell if program still crashes.
Also give me what is your Linux version and libc version + how do you
compile program and CppCMS.

In any case I need a crashing sample to debug the issue.


Artyom



      

Re: [Cppcms-users] SIGABRT problem raised between SVN rev1474 and 1491

[Julian P. <ju...@wh...>]

>
> I don't see any issues in the code and location valgrind is posting.
>
> Also I tryid to run a full build and test on x86 machine - no issues.
>
> 1. Make sure that you fully recompile your own code after building and
> installing latest CppCMS.
>
> 2. If this still happens please provide minimal code sample that reproduces
>     the problem, without it I can't do anything and I may only assume that
>     memory corruption happens in your code.
>

Hallo,

I see your point and will try to provide a sample tomorrow. I 
nevertheless think that it must have at least something to do with your 
changes between the two revisions mentioned, because with the same code 
on my side (of course, recompiled for the revision to be tested) with 
the earlier revision everything works smooth while it doesn't with the 
latter revision.
Couldn't the invalid write mentioned in valgrind's outputs lead to the 
SIGABRT?
What I don't understand anyway is
1. Why does the SIGABRT occur when running without any debugger attached 
or with gdb, but not with valgrind? The program runs (besides of the 
given log output) without any problems, but of course slower than 
normal. Even if my application doesn't use more than one thread at this 
time and cppcms::service ist not started at that point, it almost looks 
like a Race condition, but how could that be when only one thread is 
running?
2. Why, at all, is it a SIGABRT and not a SIGSEGV? According to the 
output it is a memory access violation and should be a SIGSEGV then, I 
think.

What I do in the method where the crash occurs is basically the following:

- Given is a std::vector of std::strings (filepaths) as reference
- I iterate through the vector, and for each of the strings I call a 
method which tries to open the given filepath and, if successful, loads 
it via
is >> v; to a json::value, where is is a std::ifstream.
- Then, another method is invoked to parse this value. A bad_value_cast 
exception may be thrown if the file has an invalid format
- If the first method is not successful in loading any of the given 
files, it throws a bad_cast exception like the following:
throw(cppcms::json::bad_value_cast("None of the given files could be 
loaded."));
Could it be that you changed the implementation of bad_value_cast so 
that an instantiation like this is not possible anymore?

THanks,
Julian

Re: [Cppcms-users] SIGABRT problem raised between SVN rev1474 and 1491

[Artyom <art...@ya...>]

> > Hello,
> >
> > In what case does it happens can you give me a  sample source code that
> > reproduces the problem?
> >
> 
> I think  it happens if a cppcms::json::bad_cast exception is thrown. I try
> to read a  json formatted configuration file from different possible
> locations with  cppcms::json, and if it is not formatted properly, a
> bad_cast exception  should be thrown which I catch and then try the next
> possible location.

I don't see any issues in the code and location valgrind is posting.

Also I tryid to run a full build and test on x86 machine - no issues.

1. Make sure that you fully recompile your own code after building and 
installing latest CppCMS.

2. If this still happens please provide minimal code sample that reproduces
   the problem, without it I can't do anything and I may only assume that 
   memory corruption happens in your code.

Regards,
  Artyom



      

Re: [Cppcms-users] SIGABRT problem raised between SVN rev1474 and 1491

[Julian P. <ju...@wh...>]

> Hello,
>
> In what case does it happens can you give me a sample source code that
> reproduces the problem?
>

I think it happens if a cppcms::json::bad_cast exception is thrown. I try
to read a json formatted configuration file from different possible
locations with cppcms::json, and if it is not formatted properly, a
bad_cast exception should be thrown which I catch and then try the next
possible location.
In valgrind, the program runs without crashing (I don't understand this),
but it outputs a lot of invalid reads related to a std::string instance of
a cppcms::json::bad_cast instance.
Although, with and without gdb the program crashes as described.

Valgrind output is attached.

Thanks,
Julian

Re: [Cppcms-users] SIGABRT problem raised between SVN rev1474 and 1491

[Artyom <art...@ya...>]

Hello,

In what case does it happens can you give me a sample source code that 
reproduces the problem?

Artyom


> Hallo,
> 
> a SIGABRT problem occured for me when I switched from cppcms rev.  1474 to
> 1491.
> This is the trace, the problem seems to be located in  libbooster:
> 
> *** glibc detected *** bin/myserver.fcgi: malloc(): memory  corruption:
> 0x0927c878 ***

No, this does not mean that the problem is booster as memory corruption
can happen anywhere and libc detects it afterwards, do you see anything
unusual in valgrind (if you know how to use it and have it)?

Artyom


      

[Cppcms-users] SIGABRT problem raised between SVN rev1474 and 1491

[Julian P. <ju...@wh...>]

Hallo,

a SIGABRT problem occured for me when I switched from cppcms rev. 1474 to
1491.
This is the trace, the problem seems to be located in libbooster:

*** glibc detected *** bin/myserver.fcgi: malloc(): memory corruption:
0x0927c878 ***
======= Backtrace: =========
/lib/libc.so.6[0xf720b935]
/lib/libc.so.6[0xf720ded2]
/lib/libc.so.6(__libc_malloc+0x96)[0xf720f676]
/usr/lib/libstdc++.so.6(_Znwj+0x27)[0xf73cb2d7]
/usr/lib/libbooster.so.0(_ZNSt6vectorIPvSaIS0_EE14_M_fill_insertEN9__gnu_cxx17__normal_iteratorIPS0_S2_EEjRKS0_+0x24d)[0xf766627d]
/usr/lib/libcppcms.so.1(_ZN6cppcms4json14bad_value_castC1ERKSs+0x72)[0xf74f19f2]
bin/myserver.fcgi(_ZN7msrv14NetworkHandler10loadConfigERSt6vectorISsSaISsEE+0x72)[0x8069182]
bin/myserver.fcgi(main+0x57d)[0x80565fd]
/lib/libc.so.6(__libc_start_main+0xe5)[0xf71b7455]
bin/myserver.fcgi[0x8054c91]

Reproducibility is always: Switch between libcppcms SVN 1474 and 1491
simply by make install in the corresponding build directory and the
problem occurs/disappears.
The problem seems to be restricted to 32bit machines: While the current
SVN revision causes no problems on 64bit, both 32bit x86 and ARM machines
are hit by this problem.

Thanks for your feedback,
Julian

Re: [Cppcms-users] Segmentation fault

[Artyom <art...@ya...>]

> 

> In short I can have time to build a Debian  package of CppCMS. Do you want I 
> send you a patch to integrate into the  CppCMS repository?.

You are welcome, it would be very nice.
Take a look on this link: http://art-blog.no-ip.info/wikipp/en/page/contrib

> Is there already code to generate Debian packages  written by  somebody?

Not that I'm aware of.

Artyom



      

Re: [Cppcms-users] Segmentation fault

[Mario P. <mp...@us...>]

2010-10-23 16:31 +0200, Artyom wrote:
> Hello,
>
> This bug should be fixed in svn trunk, in changeset 1486.
> Please try the version from SVN.
> The official version 0.99.4 will be released soon with this fix.
>
> Artyom
>

I tried it and now it works perfectly. Thanks a lot!

In short I can have time to build a Debian package of CppCMS. Do you want I 
send you a patch to integrate into the CppCMS repository?. Is there already 
code to generate Debian packages written by somebody?


Mario

Re: [Cppcms-users] Segmentation fault

[Artyom <art...@ya...>]

Hello,

This bug should be fixed in svn trunk, in changeset 1486. 
Please try the version from SVN.
The official version 0.99.4 will be released soon with this fix.

Artyom


> 2010-10-20 19:30 +0200, Mario Palomo wrote:
>  > Hello,
>  >
>  >  I'm starting to use CppCMS ("cppcms-0.99.3.tar.bz2" downloaded from
>  >  SourceForge), and noticed that when generating very long responses, the
>  >  executable ends with a segfault. I am using the built-in server, and I  
>reduced
>  > the code to the following:
>  >
> [...]
> 
> If it  helps, I have written an equivalent asynchronous application, and the 
> error  does NOT  occur:
> 


      

Re: [Cppcms-users] Strange bug on reading files to response().out()

[Artyom <art...@ya...>]

Hello,

this should be fixed in changeset 1486

Please take the version from trunk.
(The segfault should be fixed as well)

Artyom



----- Original Message ----
> From: Julian Pietron <ju...@wh...>
> To: cpp...@li...
> Sent: Wed, October 20, 2010 9:36:11 PM
> Subject: [Cppcms-users] Strange bug on reading files to response().out()
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hallo,
> 
> for  testing purposes I implemented a (very) basic static file server.
> This server  works very well on 64bit-architectures, but on 32bit
> architectures larger  files are only sent incompletely to the client and
> the thread the request had  been assigned to is blocked.
> 
> This is the code I use for reading file to  out:
> 
> void StaticFileServer::static(std::string path)  {
>     
>     /* Some checks to get real path  and check whether path is in a
> specified webroot etc.*/
>      /* ... */
>     
>     std::ifstream  ifile(path.c_str());
>     if(ifile.good())  {
>         response().out() <<  ifile.rdbuf();
>     }
>     std::cout <<  "Static serving completed." << std::endl; // This one is
> shown, so this  method completes successfully
> }
> 
> On 64bit, this code will read the file  specified by path to the browser
> that requests it, as it seems without  matters of size (or perhaps I did
> not try to send a file which was large  enough), on 32bit and with larger
> files, like e.g. the jquery.js of the  jQuery library, it sents only part
> of the file (file is interrupted abruptly)  and closes connection, but
> the thread still keeps blocked by the request  (testing with
> worker_threads set to 1, no further requests are possible, I  think
> because there are no threads left which are not busy). Termination  with
> SIGINT is not possible, the server application has to be killed  by
> SIGKILL. valgrind shows no significant errors.
> Sending out ad-hoc  generated HTML of any length (at least, of quite big
> sizes) works without  problems.
> The cppcms::application subclass is mounted with a factory  as
> synchronous application.
> I'm sorry that I can't provide you with more  information because I
> simply don't know what other helpful information I  could get beside the
> valgrind outputs which show no errors related to this  problem. Of course
> I will provide more information on your  request.
> 
> Thanks for your help,
> Julian
> -----BEGIN PGP  SIGNATURE-----
> Version: GnuPG v2.0.16 (GNU/Linux)
> Comment: Using GnuPG  with Mozilla -  http://enigmail.mozdev.org/
> 
> iQIcBAEBAgAGBQJMv0SrAAoJENidYKvYQHlQPF0QAJ1VlHxyBzio/FW46bq+xe1F
> 5/PliULKo9Wie3WhdS5F322HGmqY5G0ZemjoD61Xe+HBxf0C04TD0gT12vh7mN9Z
> gaqV31T/Q4QjreVles3SwetT4Oc577w07p3rUekHr05eMhV6dSDwyphY/BEAgbzd
> q811E1P8r2vaTRdfns7HDRq8lXw5Jf/fN2qwALUG02UUV7vHyGNZtMsHv8JostG2
> EuamIzZpVxrZf1hJPW1HiLRMsG1fTKbyqxYoMMXFhSYN/v7rlb9zOhgpJWBAFlBw
> uodrLzKkKDL8M7OxpzujYFitOfvfjs73cJxl2W3goRs/FfEwdWPiSlxlhPGl0ejQ
> u29C/DgyF+tcm25iuPdZndLpKPlIw4W65Oey6j6nxI/oSwu+w6XWssPHsPIGUhiz
> Ga7dxEjVrwf2qwDRgm+Tln3zjslEde9GcLnoZ7BcwNZen5e1iXHuOljRviKXUwyb
> MTxwCHksnd0y8uo47VrDfVkab3l3h0AxkBV0ZlzGcYjLB1iD9XNJxztjVpswQ5Mr
> D0dXmPWWKp2c0fzCUXZZ9qewvU1huwb+Tm/A2FGG/vYjPzH2jfp6UNBZlq7VrQvy
> /YCvcFt438WQVpQgTf7Wwoh691YraRwHuFbgB1d+YlLcYMykp0pVaHHGTjOaiWRQ
> oxGvgyFerP0SIXM/pABL
> =Sbkl
> -----END  PGP  SIGNATURE-----
> 
> ------------------------------------------------------------------------------
> Nokia  and AT&T present the 2010 Calling All Innovators-North America  contest
> Create new apps & games for the Nokia N8 for consumers in   U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly  $6M in marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish  to Ovi Store 
> http://p.sf.net/sfu/nokia-dev2dev
> _______________________________________________
> Cppcms-users  mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppcms-users
> 


      

Re: [Cppcms-users] using javascript source files/libraries...

[Vazgen K. <va...@ya...>]

Yep, that works for me!
Thanks a lot!


----- Original Message ----
From: Artyom <art...@ya...>
To: cpp...@li...
Sent: Fri, October 22, 2010 12:48:32 AM
Subject: Re: [Cppcms-users] using javascript source files/libraries...

Hello,

Read 
this: http://art-blog.no-ip.info/wikipp/en/page/cppcms_1x_config#file\_server

Generally you need to specify file_server.enable and probably 
file_server.document_root if "." is not ok.


> 
> Hello,
> I'm not an expert in web development, so this may be something  trivial. I'm 
> actually trying to use a javascript file called json2.js and in  my hello_world 
>
>
> example I added a line:
> <script  src='json2.js'></script>
> Then when trying to run the application as  a standalone server (i.e. by 
>running 
>
> ./hello_world -c config.js) I'm getting  the following error in my browser:
> "NetworkError: 404 Not Found -  http://localhost:8080/json2.js"
> 
> What do I do wrong? It looks like it does  not see the current directory as 
>root, 
>
> no? What's the way of specifying root  directory if so? Note that when I save 
>the 
>
> same html in a file and open it -  it works just fine.
> 
> Thanks, 
> Vazgen.


Artyom



      

------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
_______________________________________________
Cppcms-users mailing list
Cpp...@li...
https://lists.sourceforge.net/lists/listinfo/cppcms-users



      

Re: [Cppcms-users] using javascript source files/libraries...

[Artyom <art...@ya...>]

Hello,

Read 
this: http://art-blog.no-ip.info/wikipp/en/page/cppcms_1x_config#file\_server

Generally you need to specify file_server.enable and probably 
file_server.document_root if "." is not ok.


> 
> Hello,
> I'm not an expert in web development, so this may be something  trivial. I'm 
> actually trying to use a javascript file called json2.js and in  my hello_world 
>
> example I added a line:
> <script  src='json2.js'></script>
> Then when trying to run the application as  a standalone server (i.e. by 
>running 
>
> ./hello_world -c config.js) I'm getting  the following error in my browser:
> "NetworkError: 404 Not Found -  http://localhost:8080/json2.js"
> 
> What do I do wrong? It looks like it does  not see the current directory as 
>root, 
>
> no? What's the way of specifying root  directory if so? Note that when I save 
>the 
>
> same html in a file and open it -  it works just fine.
> 
> Thanks, 
> Vazgen.


Artyom



      

[Cppcms-users] using javascript source files/libraries...

[Vazgen K. <va...@ya...>]

Hello,
I'm not an expert in web development, so this may be something trivial. I'm 
actually trying to use a javascript file called json2.js and in my hello_world 
example I added a line:
<script src='json2.js'></script>
Then when trying to run the application as a standalone server (i.e. by running 
./hello_world -c config.js) I'm getting the following error in my browser:
"NetworkError: 404 Not Found - http://localhost:8080/json2.js"

What do I do wrong? It looks like it does not see the current directory as root, 
no? What's the way of specifying root directory if so? Note that when I save the 
same html in a file and open it - it works just fine.

Thanks, 
Vazgen.


      

Re: [Cppcms-users] Segmentation fault

[Artyom <art...@ya...>]

>  >
>  >  I'm starting to use CppCMS ("cppcms-0.99.3.tar.bz2" downloaded from
>  >  SourceForge), and noticed that when generating very long responses, the
>  >  executable ends with a segfault. I am using the built-in server, and I  
>reduced
>  > the code to the following:
>  >
> [...]
> 
> If it  helps, I have written an equivalent asynchronous application, and the 
> error  does NOT  occur:
> 
> [...]
> 
> When  do you recommend using an application of one type or the other?
> 
> Best  regards,
> 
> Mario
> 

No, it is just a bug I had already reproduced and I have a direction to fix it.
What happens that the connection socket incorrectly remains in non-blocking
mode causing a fault when getting to EWOULDBLOCK in synchronous mode, of course
this does not happen in async mode as EWOULDBLOCK is expected.

It is just little bit more complex then "few lines of fix"

I'll fix this bug ASAP and I'll let you know, hopefully today or tomorrow it 
would be done.

Artyom


      

Re: [Cppcms-users] Segmentation fault

[Mario P. <mp...@us...>]

2010-10-20 19:30 +0200, Mario Palomo wrote:
 > Hello,
 >
 > I'm starting to use CppCMS ("cppcms-0.99.3.tar.bz2" downloaded from
 > SourceForge), and noticed that when generating very long responses, the
 > executable ends with a segfault. I am using the built-in server, and I reduced
 > the code to the following:
 >
[...]

If it helps, I have written an equivalent asynchronous application, and the 
error does NOT occur:

______________________________________________________________________________
/*
    bench.cpp
*/
#include <cppcms/application.h>
#include <cppcms/applications_pool.h>
#include <cppcms/service.h>
#include <cppcms/http_response.h>
#include <iostream>

class bench : public cppcms::application
{
public:
   bench(cppcms::service &srv) : cppcms::application(srv) { }

   virtual void main(std::string url)
   {
     for (int i=0; i < 100000; ++i) {
       response().out() << i << "\n";
     }
     release_context()->async_complete_response();
   }//main
};//class bench

int main(int argc, char *argv[])
{
   try {
     cppcms::service srv(argc, argv);
     booster::intrusive_ptr<bench> app = new bench(srv);
     srv.applications_pool().mount(app);
     srv.run();
   }
   catch (const std::exception &e) {
     std::cerr << e.what() << std::endl;
   }

   return 0;
}//main
______________________________________________________________________________

______________________________________________________________________________
//config.js
{
   "service": {
     "api": "http",
     "port": 8080,
   },
   "http": {
     "script_names": [ "/bench" ],
   },
}
______________________________________________________________________________


When do you recommend using an application of one type or the other?

Best regards,

Mario

Re: [Cppcms-users] Cookies in asynchronous applications

[Artyom <art...@ya...>]

This is done by design,
Because session data load may be not cheap (for example request from DB)

See: 
http://cppcms.sourceforge.net/cppcms_ref_v0_99/classcppcms_1_1session__interface.html#_details


just call load() function:

http://cppcms.sourceforge.net/cppcms_ref_v0_99/classcppcms_1_1session__interface.html#e63e68dd2ec1d615f5a6a85bcee36605


Artyom





----- Original Message ----
> From: "ju...@ne..." <ju...@ne...>
> To: cpp...@li...
> Sent: Thu, October 21, 2010 3:13:41 PM
> Subject: [Cppcms-users] Cookies in asynchronous applications
> 
> Hallo,
> 
> as it seems, my sessions set by synchronous applications (for  login etc.)
> cannot be retrieved in an asynchronous application. While in  any
> synchronous application I have mounted the call  to
> context().session().is_set("sessionId") returns true, in my  asynchronous
> application it returns false while the session cookie is still  set in
> browser. Session data is completely stored in cookies, because I have  not
> much to store.
> 
> How can I retrieve the requesting browser's  session?
> 
> Thanks,
> Julian
> 
> 
> ------------------------------------------------------------------------------
> Nokia  and AT&T present the 2010 Calling All Innovators-North America  contest
> Create new apps & games for the Nokia N8 for consumers in   U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly  $6M in marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish  to Ovi Store 
> http://p.sf.net/sfu/nokia-dev2dev
> _______________________________________________
> Cppcms-users  mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppcms-users
> 


      

[Cppcms-users] Cookies in asynchronous applications

[<ju...@ne...>]

Hallo,

as it seems, my sessions set by synchronous applications (for login etc.)
cannot be retrieved in an asynchronous application. While in any
synchronous application I have mounted the call to
context().session().is_set("sessionId") returns true, in my asynchronous
application it returns false while the session cookie is still set in
browser. Session data is completely stored in cookies, because I have not
much to store.

How can I retrieve the requesting browser's session?

Thanks,
Julian

Re: [Cppcms-users] Segmentation fault

[Mario P. <mp...@us...>]

2010-10-20 23:21 +0200, Artyom wrote:
> I hadn't reproduced the crash bug, but there is other but that seems to be
> related,
> I'm working on it that may cause the crash.
>
> Also can you send me the backtrace of the crash?
>
> You can do it with gdb this way:
> Compile with "-g" switch and then in gdb
>
>> r -c config.js
> --- Observer Crash
>> bt
> ..... this is trace
>
>
> Artyom
>

Here it is:

$ g++ -g -o bench bench.cpp -Wall -I/home/mario/cppcms/include 
-L/home/mario/cppcms/lib -lcppcms -lbooster
$ LD_LIBRARY_PATH=/home/mario/cppcms/lib gdb ./bench
GNU gdb (GDB) 7.2-debian
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/mario/cppcms/bench...done.
(gdb) r -c config.js
Starting program: /home/mario/cppcms/bench -c config.js
[Thread debugging using libthread_db enabled]
[New Thread 0x7ffff45a1710 (LWP 2739)]
[New Thread 0x7ffff3da0710 (LWP 2740)]
[New Thread 0x7ffff359f710 (LWP 2741)]
[New Thread 0x7ffff2d9e710 (LWP 2742)]
[New Thread 0x7ffff259d710 (LWP 2743)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff359f710 (LWP 2741)]
0x00007ffff7a88708 in cppcms::impl::cgi::connection::write (this=0x648c60, 
data=<value optimized out>, n=16384) at 
/home/mario/isla/cppcms-0.99.3/src/cgi_api.cpp:476
476                     size_t d=write_some(p,n);
(gdb) bt
#0  0x00007ffff7a88708 in cppcms::impl::cgi::connection::write (this=0x648c60, 
data=<value optimized out>, n=16384) at 
/home/mario/isla/cppcms-0.99.3/src/cgi_api.cpp:476
#1  0x00007ffff7a99423 in write (this=0x649610) at 
/home/mario/isla/cppcms-0.99.3/src/http_response.cpp:83 

#2  write<cppcms::http::<unnamed>::output_device> (this=0x649610) at 
/home/mario/isla/cppcms-0.99.3/cppcms_boost/cppcms_boost/iostreams/write.hpp:121 

#3  write<cppcms::http::<unnamed>::output_device> (this=0x649610) at 
/home/mario/isla/cppcms-0.99.3/cppcms_boost/cppcms_boost/iostreams/write.hpp:53 

#4  write<cppcms::http::<unnamed>::output_device, 
cppcms_boost::iostreams::detail::linked_streambuf<char, std::char_traits<char> 
 > > (this=0x649610)
     at 
/home/mario/isla/cppcms-0.99.3/cppcms_boost/cppcms_boost/iostreams/detail/adapter/concept_adapter.hpp:188 

#5  write<cppcms_boost::iostreams::detail::linked_streambuf<char, 
std::char_traits<char> > > (this=0x649610) 

     at 
/home/mario/isla/cppcms-0.99.3/cppcms_boost/cppcms_boost/iostreams/detail/adapter/concept_adapter.hpp:82 

#6 
cppcms_boost::iostreams::detail::indirect_streambuf<cppcms::http::<unnamed>::output_device, 
std::char_traits<char>, std::allocator<char>, 
cppcms_boost::iostreams::output>::sync_impl(void) (this=0x649610) at 
/home/mario/isla/cppcms-0.99.3/cppcms_boost/cppcms_boost/iostreams/detail/streambuf/indirect_streambuf.hpp:392 

#7  0x00007ffff7a99509 in 
cppcms_boost::iostreams::detail::indirect_streambuf<cppcms::http::<unnamed>::output_device, 
std::char_traits<char>, std::allocator<char>, 
cppcms_boost::iostreams::output>::sync(void) (this=0x648c60) at 
/home/mario/isla/cppcms-0.99.3/cppcms_boost/cppcms_boost/iostreams/detail/streambuf/indirect_streambuf.hpp:312 

#8  0x00007ffff7a993aa in 
cppcms_boost::iostreams::detail::indirect_streambuf<cppcms::http::<unnamed>::output_device, 
std::char_traits<char>, std::allocator<char>, 
cppcms_boost::iostreams::output>::close_impl(std::_Ios_Openmode) 
(this=0x649610, which=<value optimized out>) 

     at 
/home/mario/isla/cppcms-0.99.3/cppcms_boost/cppcms_boost/iostreams/detail/streambuf/indirect_streambuf.hpp:375 

#9  0x00007ffff7a9ff35 in close (op=..., c0=...) at 
/home/mario/isla/cppcms-0.99.3/cppcms_boost/cppcms_boost/iostreams/detail/streambuf/linked_streambuf.hpp:82 

#10 operator() (op=..., c0=...) at 
/home/mario/isla/cppcms-0.99.3/cppcms_boost/cppcms_boost/iostreams/detail/functional.hpp:116 

#11 
cppcms_boost::iostreams::detail::execute_all<cppcms_boost::iostreams::detail::member_close_operation<cppcms_boost::iostreams::detail::linked_streambuf<char, 
std::char_traits<char> > >, 
cppcms_boost::iostreams::detail::member_close_operation<cppcms_boost::iostreams::detail::linked_streambuf<char, 
std::char_traits<char> > > > (op=..., c0=...)
     at 
/home/mario/isla/cppcms-0.99.3/cppcms_boost/cppcms_boost/preprocessor/iteration/detail/local.hpp:37 

#12 0x00007ffff7a99725 in 
execute_all<cppcms_boost::iostreams::detail::member_close_operation<cppcms_boost::iostreams::detail::linked_streambuf<char, 
std::char_traits<char> > >, 
cppcms_boost::iostreams::detail::member_close_operation<cppcms_boost::iostreams::detail::linked_streambuf<char, 
std::char_traits<char> > >, 
cppcms_boost::iostreams::detail::reset_operation<cppcms_boost::iostreams::detail::optional<cppcms_boost::iostreams::detail::concept_adapter<cppcms::http::<unnamed>::output_device> 
 > > > (op=..., c0=..., c1=..., c2=...)
     at 
/home/mario/isla/cppcms-0.99.3/cppcms_boost/cppcms_boost/preprocessor/iteration/detail/local.hpp:40 

#13 
cppcms_boost::iostreams::detail::execute_all<cppcms_boost::iostreams::detail::member_close_operation<cppcms_boost::iostreams::detail::linked_streambuf<char, 
std::char_traits<char> > >, 
cppcms_boost::iostreams::detail::member_close_operation<cppcms_boost::iostreams::detail::linked_streambuf<char, 
std::char_traits<char> > >, 
cppcms_boost::iostreams::detail::reset_operat---Type <return> to continue, or q 
<return> to quit--- 

ion<cppcms_boost::iostreams::detail::optional<cppcms_boost::iostreams::detail::concept_adapter<cppcms::http::<unnamed>::output_device> 
 > >, cppcms_boost::iostreams::detail::clear_flags_operation<int> 
 >(cppcms_boost::iostreams::detail::member_close_operation<cppcms_boost::iostreams::detail::linked_streambuf<char, std::char_traits<char> > >, cppcms_boost::iostreams::detail::member_close_operation<cppcms_boost::iostreams::detail::linked_streambuf<char, std::char_traits<char> > >, cppcms_boost::iostreams::detail::reset_operation<cppcms_boost::iostreams::detail::optional<cppcms_boost::iostreams::detail::concept_adapter<cppcms::http::<unnamed>::output_device> > >, cppcms_boost::iostreams::detail::clear_flags_operation<int>) (op=..., c0=...,
     c1=..., c2=...) at 
/home/mario/isla/cppcms-0.99.3/cppcms_boost/cppcms_boost/preprocessor/iteration/detail/local.hpp:43
#14 0x00007ffff7a99ad1 in close (this=0x648c60, __in_chrg=<value optimized out>)
     at 
/home/mario/isla/cppcms-0.99.3/cppcms_boost/cppcms_boost/iostreams/detail/streambuf/indirect_streambuf.hpp:202
#15 
cppcms_boost::iostreams::stream_buffer<cppcms::http::<unnamed>::output_device, 
std::char_traits<char>, std::allocator<char>, 
cppcms_boost::iostreams::output>::~stream_buffer(void) (
     this=0x648c60, __in_chrg=<value optimized out>) at 
/home/mario/isla/cppcms-0.99.3/cppcms_boost/cppcms_boost/iostreams/stream_buffer.hpp:90
#16 0x00007ffff7aa3504 in ~base_from_member (this=<value optimized out>, 
__in_chrg=<value optimized out>)
     at 
/home/mario/isla/cppcms-0.99.3/cppcms_boost/cppcms_boost/utility/base_from_member.hpp:67
#17 ~stream_base (this=<value optimized out>, __in_chrg=<value optimized out>) 
at /home/mario/isla/cppcms-0.99.3/cppcms_boost/cppcms_boost/iostreams/stream.hpp:77
#18 ~stream (this=<value optimized out>, __in_chrg=<value optimized out>) at 
/home/mario/isla/cppcms-0.99.3/cppcms_boost/cppcms_boost/iostreams/stream.hpp:112
#19 ~_data (this=<value optimized out>, __in_chrg=<value optimized out>) at 
/home/mario/isla/cppcms-0.99.3/src/http_response.cpp:88
#20 booster::hold_ptr<cppcms::http::response::_data>::~hold_ptr (this=<value 
optimized out>, __in_chrg=<value optimized out>)
     at /home/mario/isla/cppcms-0.99.3/booster/booster/hold_ptr.h:27
#21 0x00007ffff7a9a1c9 in cppcms::http::response::~response (this=0x648c60, 
__in_chrg=<value optimized out>) at 
/home/mario/isla/cppcms-0.99.3/src/http_response.cpp:124
#22 0x00007ffff7aa6e69 in ~auto_ptr (this=0x6216a0, __in_chrg=<value optimized 
out>) at /usr/include/c++/4.4/backward/auto_ptr.h:168
#23 ~_data (this=0x6216a0, __in_chrg=<value optimized out>) at 
/home/mario/isla/cppcms-0.99.3/src/http_context.cpp:46
#24 ~hold_ptr (this=0x6216a0, __in_chrg=<value optimized out>) at 
/home/mario/isla/cppcms-0.99.3/booster/booster/hold_ptr.h:27
#25 cppcms::http::context::~context (this=0x6216a0, __in_chrg=<value optimized 
out>) at /home/mario/isla/cppcms-0.99.3/src/http_context.cpp:208
#26 0x00007ffff7aa90e2 in checked_delete<cppcms::http::context> (this=<value 
optimized out>) at 
/home/mario/isla/cppcms-0.99.3/booster/booster/checked_delete.h:30
#27 booster::detail::sp_counted_impl_p<cppcms::http::context>::dispose 
(this=<value optimized out>) at 
/home/mario/isla/cppcms-0.99.3/booster/booster/smart_ptr/sp_counted_impl.h:51
#28 0x00007ffff775ba56 in booster::detail::sp_counted_base::release 
(this=0x611140) at 
/home/mario/isla/cppcms-0.99.3/booster/lib/smart_ptr/src/sp_counted_base.cpp:268
#29 0x00007ffff7aad8a0 in cppcms::application::recycle (this=0x648c60) at 
/home/mario/isla/cppcms-0.99.3/src/application.cpp:214
#30 0x00007ffff7aad92b in booster::intrusive_ptr_release (app=0x650500) at 
/home/mario/isla/cppcms-0.99.3/src/application.cpp:240
---Type <return> to continue, or q <return> to quit---
#31 0x00007ffff7aa8be5 in ~intrusive_ptr (this=0x6505f0, __in_chrg=<value 
optimized out>) at 
/home/mario/isla/cppcms-0.99.3/booster/booster/intrusive_ptr.h:68
#32 ~value (this=0x6505f0, __in_chrg=<value optimized out>) at 
/home/mario/isla/cppcms-0.99.3/cppcms_boost/cppcms_boost/bind/bind.hpp:113
#33 ~storage1 (this=0x6505f0, __in_chrg=<value optimized out>) at 
/home/mario/isla/cppcms-0.99.3/cppcms_boost/cppcms_boost/bind/storage.hpp:41
#34 ~storage2 (this=0x6505f0, __in_chrg=<value optimized out>) at 
/home/mario/isla/cppcms-0.99.3/cppcms_boost/cppcms_boost/bind/storage.hpp:77
#35 ~storage3 (this=0x6505f0, __in_chrg=<value optimized out>) at 
/home/mario/isla/cppcms-0.99.3/cppcms_boost/cppcms_boost/bind/storage.hpp:126
#36 ~list3 (this=0x6505f0, __in_chrg=<value optimized out>) at 
/home/mario/isla/cppcms-0.99.3/cppcms_boost/cppcms_boost/bind/bind.hpp:346
#37 ~bind_t (this=0x6505f0, __in_chrg=<value optimized out>) at 
/home/mario/isla/cppcms-0.99.3/cppcms_boost/cppcms_boost/bind/bind.hpp:854
#38 callable_impl<void, cppcms_boost::_bi::bind_t<void, void 
(*)(booster::intrusive_ptr<cppcms::application>, std::basic_string<char, 
std::char_traits<char>, std::allocator<char> >, bool), 
cppcms_boost::_bi::list3<cppcms_boost::_bi::value<booster::intrusive_ptr<cppcms::application> 
 >, cppcms_boost::_bi::value<std::basic_string<char, std::char_traits<char>, 
std::allocator<char> > >, cppcms_boost::_bi::value<bool> > > >::~callable_impl 
(this=0x6505f0, __in_chrg=<value optimized out>) at 
/home/mario/isla/cppcms-0.99.3/booster/booster/function.h:163
#39 0x00007ffff7aaa229 in ~clone_ptr (this=0x6084e0) at 
/home/mario/isla/cppcms-0.99.3/booster/booster/clone_ptr.h:42
#40 ~function (this=0x6084e0) at 
/home/mario/isla/cppcms-0.99.3/booster/booster/function.h:16
#41 cppcms::impl::thread_pool::worker (this=0x6084e0) at 
/home/mario/isla/cppcms-0.99.3/src/thread_pool.cpp:110
#42 0x00007ffff774b29c in operator() (p=<value optimized out>) at 
/home/mario/isla/cppcms-0.99.3/booster/./booster/function.h:163
#43 booster::booster_thread_func (p=<value optimized out>) at 
/home/mario/isla/cppcms-0.99.3/booster/lib/thread/src/thread.cpp:33
#44 0x00007ffff63418ba in start_thread (arg=<value optimized out>) at 
pthread_create.c:300
#45 0x00007ffff6cb902d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#46 0x0000000000000000 in ?? ()
(gdb)


Best regards,

Mario

Re: [Cppcms-users] Failing assertion in asynchronous application

[Artyom <art...@ya...>]

> 
> The problem is: There is no  backtrace. I ran the server with valgrind,
> and after the assertion failure,  the server exits without a backtrace.
> Should I perhaps try with gdb instead  of valgrind?

Yes, run program in gdb, and when assert happens just print

> bt

And see the trace.

Arryom


> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.16  (GNU/Linux)
> Comment: Using GnuPG with Mozilla -  http://enigmail.mozdev.org/
> 
> iQIcBAEBAgAGBQJMv2gPAAoJENidYKvYQHlQldYP/1cAD19YM/YILH+qodCbofi8
> fF/JTOKEbLedqRJlVltzKuzmMArAciiNAZxY4Dp8m7sH4QfDWCsLRLkBeH8PBHtI
> YiMf+MF8ciX56VqSjW6eHSNnjTqpddm2o1QsyrT3EyUKRjSp1dADnqgg4ga4EcSn
> vwPz9az+4beIhPj+0rOZaMNf5yeq74vsSlKKBrvYIpTuUyGfONPvmGnG2H9ytsr7
> pqyVfcrCS0SazmkDVxiQorRXg+A3bY5WXd/Jv5Zun9azhSxgr+L18P5yYLmeLkre
> AIEBuOsQ/nr7BsWwZeyPL5obygY2nDjcqettZMDQHozvuvw9FpZ6mQBmXwJMNQ2K
> 0vkK77yLXD2LTmf/cYQ5b1i1TK2Wc0NPIvM8CZ8hGplQf7mmDa9aF7gcIb9sSi60
> gbl4Bg5e8jlAcmWb3+JKxPT/g4QKp+0iFl4j6/dDEMckj7SceQaqdk/jih50UCPM
> YyecVCniKtax+5mGEweA7IE1gyeQcSy8pX0ey7BiuKwyHupiFpOeBH1gAmF8Ed0Q
> tN5dBQAMw3jkIJLcvJUs1wfI9QrSLKQh0kirbEf9479niPLqG1y/DHvcQiQtX1i3
> O/qhmNUcwN7rDRkC2SlqsVdhv1017V/2LFxiKXcOVC8Mzxot/tfjZzLMmhgAv+0r
> ubMju+eym6+LKoSiVcl0
> =GRU3
> -----END  PGP  SIGNATURE-----
> 
> ------------------------------------------------------------------------------
> Nokia  and AT&T present the 2010 Calling All Innovators-North America  contest
> Create new apps & games for the Nokia N8 for consumers in   U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly  $6M in marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish  to Ovi Store 
> http://p.sf.net/sfu/nokia-dev2dev
> _______________________________________________
> Cppcms-users  mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppcms-users
> 


      

Re: [Cppcms-users] Failing assertion in asynchronous application

[Julian P. <ju...@wh...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> 
> Can you give me the backtrace?
> 
> It may be the bug that was fixed in trunk, however trunk not really stable
> at this point, so backtrace will help me to understand if this is it.
> 

The problem is: There is no backtrace. I ran the server with valgrind,
and after the assertion failure, the server exits without a backtrace.
Should I perhaps try with gdb instead of valgrind?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJMv2gPAAoJENidYKvYQHlQldYP/1cAD19YM/YILH+qodCbofi8
fF/JTOKEbLedqRJlVltzKuzmMArAciiNAZxY4Dp8m7sH4QfDWCsLRLkBeH8PBHtI
YiMf+MF8ciX56VqSjW6eHSNnjTqpddm2o1QsyrT3EyUKRjSp1dADnqgg4ga4EcSn
vwPz9az+4beIhPj+0rOZaMNf5yeq74vsSlKKBrvYIpTuUyGfONPvmGnG2H9ytsr7
pqyVfcrCS0SazmkDVxiQorRXg+A3bY5WXd/Jv5Zun9azhSxgr+L18P5yYLmeLkre
AIEBuOsQ/nr7BsWwZeyPL5obygY2nDjcqettZMDQHozvuvw9FpZ6mQBmXwJMNQ2K
0vkK77yLXD2LTmf/cYQ5b1i1TK2Wc0NPIvM8CZ8hGplQf7mmDa9aF7gcIb9sSi60
gbl4Bg5e8jlAcmWb3+JKxPT/g4QKp+0iFl4j6/dDEMckj7SceQaqdk/jih50UCPM
YyecVCniKtax+5mGEweA7IE1gyeQcSy8pX0ey7BiuKwyHupiFpOeBH1gAmF8Ed0Q
tN5dBQAMw3jkIJLcvJUs1wfI9QrSLKQh0kirbEf9479niPLqG1y/DHvcQiQtX1i3
O/qhmNUcwN7rDRkC2SlqsVdhv1017V/2LFxiKXcOVC8Mzxot/tfjZzLMmhgAv+0r
ubMju+eym6+LKoSiVcl0
=GRU3
-----END PGP SIGNATURE-----

Re: [Cppcms-users] Failing assertion in asynchronous application

[Artyom <art...@ya...>]

> 
> today I  discovered an assertion in booster::shared_ptr that fails under
> specific  circumstances in asynchronous applications.
> If a client (browser) closes the  current connection while its request is
> still served and release_context() is  called after the connection had
> been closed already, the server exits with  the following error message:


Can you give me the backtrace?

> 
> iweb2.fcgi:  booster/booster/shared_ptr.h:305:  T*
> booster::shared_ptr<T>::operator->() const [with T  =
> cppcms::impl::cgi::connection]: Assertion `px != 0' failed.
> 
> Do I  have to perform any check before I call release_context() or is
> this  considered to be a bug?

It may be the bug that was fixed in trunk, however trunk not really stable
at this point, so backtrace will help me to understand if this is it.

Artyom



      

Re: [Cppcms-users] Segmentation fault

[Artyom <art...@ya...>]

I hadn't reproduced the crash bug, but there is other but that seems to be 
related,
I'm working on it that may cause the crash.

Also can you send me the backtrace of the crash?

You can do it with gdb this way:
Compile with "-g" switch and then in gdb

> r -c config.js
--- Observer Crash
> bt
..... this is trace


Artyom


----- Original Message ----
> From: Mario Palomo <mp...@us...>
> To: cpp...@li...
> Sent: Wed, October 20, 2010 7:30:07 PM
> Subject: [Cppcms-users] Segmentation fault
> 
> Hello,
> 
> I'm starting to use CppCMS ("cppcms-0.99.3.tar.bz2" downloaded  from 
> SourceForge), and noticed that when generating very long responses, the 
> executable ends with a segfault. I am using the built-in server, and I  reduced 
>
> the code to the  following:
> 
> ______________________________________________________________________________
> /*
>     bench.cpp
> */
> #include <cppcms/application.h>
> #include  <cppcms/applications_pool.h>
> #include  <cppcms/service.h>
> #include <cppcms/http_response.h>
> #include  <iostream>
> 
> class bench : public  cppcms::application
> {
> public:
>    bench(cppcms::service &srv) :  cppcms::application(srv) { }
> 
>    virtual void main(std::string  url)
>    {
>      for (int i=0; i < 100000; ++i)  {
>        response().out() << i << "\n";
>       }
>    }//main
> };//class bench
> 
> int main(int argc, char  *argv[])
> {
>    try {
>      cppcms::service srv(argc,  argv);
>       srv.applications_pool().mount(cppcms::applications_factory<bench>());
>       srv.run();
>    }
>    catch (const std::exception &e)  {
>      std::cerr << e.what() << std::endl;
>     }
> 
>    return  0;
> }//main
> ______________________________________________________________________________
> 
> ______________________________________________________________________________
> /*
>     config.js
> */
> {
>    "service": {
>      "api":  "http",
>      "port": 8080,
>    },
>    "http":  {
>      "script_names": [ "/bench" ],
>     },
> }
> ______________________________________________________________________________
> 
> 
> I  start the application:
> 
>    $ ./bench -c config.js
> 
> Then, I use  "curl" to make a request:
> 
>    $ curl  http://localhost:8080/bench
> 
> And the application ("bench") terminates with  a segmentation fault.
> 
> A backtrace shows that the last statement that is  executed is the line 476 of 

> file "cgi_api.cpp" ('write_some()' in function  'connection::write()'), but so 

> far I have not gotten more  information.
> 
> Can anyone else reproduce the problem? Can be solved if I  use the latest 
> version in SVN? (I'll try to test soon with the latest  version of the code).
> 
> Thank you for creating something as awesome as  CppCMS.  Regards,
> 
> Mario
> 
> 
> 
> ------------------------------------------------------------------------------
> Nokia  and AT&T present the 2010 Calling All Innovators-North America  contest
> Create new apps & games for the Nokia N8 for consumers in  U.S.  and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in  marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi  Store 
> http://p.sf.net/sfu/nokia-dev2dev
> _______________________________________________
> Cppcms-users  mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppcms-users
> 


      

Re: [Cppcms-users] Strange bug on reading files to response().out()

[Artyom <art...@ya...>]

Looks like I found the bug, working on it.

Artyom


> On 64bit, this code will read the file  specified by path to the browser
> that requests it, as it seems without  matters of size (or perhaps I did
> not try to send a file which was large  enough), on 32bit and with larger
> files, like e.g. the jquery.js of the  jQuery library, it sents only part
> of the file (file is interrupted abruptly)  and closes connection,


      

[Cppcms-users] Failing assertion in asynchronous application

[Julian P. <ju...@wh...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hallo,

today I discovered an assertion in booster::shared_ptr that fails under
specific circumstances in asynchronous applications.
If a client (browser) closes the current connection while its request is
still served and release_context() is called after the connection had
been closed already, the server exits with the following error message:

iweb2.fcgi: booster/booster/shared_ptr.h:305: T*
booster::shared_ptr<T>::operator->() const [with T =
cppcms::impl::cgi::connection]: Assertion `px != 0' failed.

Do I have to perform any check before I call release_context() or is
this considered to be a bug?

Thanks,
Julian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJMv0VeAAoJENidYKvYQHlQ8ZIP/jRmzk3USLq1XcKl+NTlYk3p
8ODzLZtOt5Fh7H+PJPwWW2jN7g/ZI+V+zA6PAWa5szSwRbJLrmrI2heEtPRZ8M+a
GbIWHBM52zmX1xfkT3Dnamxl8Wq82ZFA/NzTI3rFw1GKEy6oa9d97zHdd8MVysXZ
6N2ILEhTyDZELsJnsOj4kT/7PTuZIpVPoDgn9jwgNeHroJFcAH251zCIllbI0y5V
Uv5youqdYxlabYxifwhoQOACDg3MWHaytBn6Fw8g84Tv5u7ebN6vnfDWL+m2rEWm
EvUpFHoCHfnxAyh1010Zf5oNMFyu+qrEzND/CLs9CF3cCHAWPhxUkDmHmTDIy5rn
TaBCMVZVNZ2JmO84rzXWluwTfj/cFVR1b9W8iDUri2Dy+hXyGePmhVpMgWVc5SH5
Wh2cv8IoQMfg8Pc4GkfV0dTNGAOaRkyXhxNrVpmA3Sx9RmiZZ0sjni5eKhVk2I0D
+3IZ1X5lc5373NuMQTfl6CoQcUkbJ9JqyhskLrakU3YrHGngsk9FVdDbC7NiqFWW
42wPx6kNlWfX16VTEm9L+vyoDW/dLUWrdEdOrovKob0lM310m/7oiG/OxR8qzFeS
9cejAv7y/2mePBe3vyhTN/6DmKyokyjTIiXWgErqrAOAWaq/ph3zFQ64/YaJva0Y
ezoQ4CeSBf33XgmPODBt
=WGr3
-----END PGP SIGNATURE-----

[Cppcms-users] Strange bug on reading files to response().out()

[Julian P. <ju...@wh...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hallo,

for testing purposes I implemented a (very) basic static file server.
This server works very well on 64bit-architectures, but on 32bit
architectures larger files are only sent incompletely to the client and
the thread the request had been assigned to is blocked.

This is the code I use for reading file to out:

void StaticFileServer::static(std::string path) {
	
	/* Some checks to get real path and check whether path is in a
specified webroot etc.*/
	/* ... */
	
	std::ifstream ifile(path.c_str());
	if(ifile.good()) {
		response().out() << ifile.rdbuf();
	}
	std::cout << "Static serving completed." << std::endl; // This one is
shown, so this method completes successfully
}

On 64bit, this code will read the file specified by path to the browser
that requests it, as it seems without matters of size (or perhaps I did
not try to send a file which was large enough), on 32bit and with larger
files, like e.g. the jquery.js of the jQuery library, it sents only part
of the file (file is interrupted abruptly) and closes connection, but
the thread still keeps blocked by the request (testing with
worker_threads set to 1, no further requests are possible, I think
because there are no threads left which are not busy). Termination with
SIGINT is not possible, the server application has to be killed by
SIGKILL. valgrind shows no significant errors.
Sending out ad-hoc generated HTML of any length (at least, of quite big
sizes) works without problems.
The cppcms::application subclass is mounted with a factory as
synchronous application.
I'm sorry that I can't provide you with more information because I
simply don't know what other helpful information I could get beside the
valgrind outputs which show no errors related to this problem. Of course
I will provide more information on your request.

Thanks for your help,
Julian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJMv0SrAAoJENidYKvYQHlQPF0QAJ1VlHxyBzio/FW46bq+xe1F
5/PliULKo9Wie3WhdS5F322HGmqY5G0ZemjoD61Xe+HBxf0C04TD0gT12vh7mN9Z
gaqV31T/Q4QjreVles3SwetT4Oc577w07p3rUekHr05eMhV6dSDwyphY/BEAgbzd
q811E1P8r2vaTRdfns7HDRq8lXw5Jf/fN2qwALUG02UUV7vHyGNZtMsHv8JostG2
EuamIzZpVxrZf1hJPW1HiLRMsG1fTKbyqxYoMMXFhSYN/v7rlb9zOhgpJWBAFlBw
uodrLzKkKDL8M7OxpzujYFitOfvfjs73cJxl2W3goRs/FfEwdWPiSlxlhPGl0ejQ
u29C/DgyF+tcm25iuPdZndLpKPlIw4W65Oey6j6nxI/oSwu+w6XWssPHsPIGUhiz
Ga7dxEjVrwf2qwDRgm+Tln3zjslEde9GcLnoZ7BcwNZen5e1iXHuOljRviKXUwyb
MTxwCHksnd0y8uo47VrDfVkab3l3h0AxkBV0ZlzGcYjLB1iD9XNJxztjVpswQ5Mr
D0dXmPWWKp2c0fzCUXZZ9qewvU1huwb+Tm/A2FGG/vYjPzH2jfp6UNBZlq7VrQvy
/YCvcFt438WQVpQgTf7Wwoh691YraRwHuFbgB1d+YlLcYMykp0pVaHHGTjOaiWRQ
oxGvgyFerP0SIXM/pABL
=Sbkl
-----END PGP SIGNATURE-----