Hello,
I have a small MFC app ported to winelib which uses MFC compiled with winelib. Really, it is just an App-Wizard generated application. I always have a crash of the application after printing. The page is printed ok but after that the app crashes. I use LPD for printing and my command line from wine is 'lpr -P<myprinter>'. I also try to print without MFC support i.e creating the printer DC by hand etc - the crash is the same, it follows EndDoc() call.
There is no crash like this at the same linux configuration using in a 'pure' Win32 simple application without MFC though the code for printing is the same.
When i print to file, all is ok. So , my current workaround is printing to a temp file and then send the file to lpr.
I use RH9.0, wine20050419. My [spooler] section in config is the default from the wine installation.
Did anybody meet a problem like that ? Is it MFC that has some impact here ? Thanks a lot for any hints.
Eugene Aksenov wrote:
I have a small MFC app ported to winelib which uses MFC compiled with winelib. Really, it is just an App-Wizard generated application. I always have a crash of the application after printing. The page is printed ok but after that the app crashes. [...] Did anybody meet a problem like that ? Is it MFC that has some impact here ? Thanks a lot for any hints.
I've run into this bug & fixed it. I just was never confident enough in my fix to get around to submitting it.
The problem you're seeing is most likely because you have a C++ application. When wine prints something via lpr, it forks off a child process to do the printing. Instead of doing exec("lpr") as most other programs do, wine does a system("lpr"); exit(); The normal exit causes the child process to execute global destructors, which the 'exec' wouldn't. If the global destructors free memory that is also used by the parent process (which is probably common), the parent process will quickly crash.
Try the attached patch and see if it fixes your problem. I think it's mostly correct for linux, solaris, and hp. We'd need to check the behavior of system() on other platforms to make sure it's consistent. On Solaris, it looks like there are circumstances when system() will invoke 'ksh' instead of 'sh', but I hope wine doesn't need to worry too much about that little detail.
Eric
Index: printdrv.c =================================================================== --- printdrv.c (.../vendor/wine/current/dlls/gdi/printdrv.c) (revision 30779) +++ printdrv.c (.../trunk/wine/dlls/gdi/printdrv.c) (revision 30779) @@ -516,9 +516,13 @@ signal( SIGPIPE, SIG_DFL ); signal( SIGCHLD, SIG_DFL );
- system(psCmdP); +#if defined(__hpux) || (defined(__sun) && defined(__SVR4)) + execl("/usr/bin/sh", "sh", "-c", psCmdP, 0); +#else + execl("/bin/sh", "sh", "-c", psCmdP, 0); +#endif + /* If the exec fails, we'll just take our chances and exit */ exit(0); - } close (fds[0]); fd = fds[1];
Hello Eric
Yes, this patch fixes the problem. Thanks for the description. I checked on linux only. Perhaps, the patch is to be submitted.
-- Eugene
Eugene Aksenov wrote:
I have a small MFC app ported to winelib which uses MFC compiled with winelib. Really, it is just an App-Wizard generated application. I always have a crash of the application after printing. The page is printed ok but after that the app crashes. [...] Did anybody meet a problem like that ? Is it MFC that has some impact here ? Thanks a lot for any hints.
I've run into this bug & fixed it. I just was never confident enough in my fix to get around to submitting it.
The problem you're seeing is most likely because you have a C++ application. When wine prints something via lpr, it forks off a child process to do the printing. Instead of doing exec("lpr") as most other programs do, wine does a system("lpr"); exit(); The normal exit causes the child process to execute global destructors, which the 'exec' wouldn't. If the global destructors free memory that is also used by the parent process (which is probably common), the parent process will quickly crash.
Try the attached patch and see if it fixes your problem. I think it's mostly correct for linux, solaris, and hp. We'd need to check the behavior of system() on other platforms to make sure it's consistent. On Solaris, it looks like there are circumstances when system() will invoke 'ksh' instead of 'sh', but I hope wine doesn't need to worry too much about that little detail.
Eric
-
Eric Frias -
Eugene Aksenov