Windows 11 pro service crash in HTTPServerConnection::run() with new Intel Core Ultra Processors (Series 2)

[micheleselea]

Hi all, ok this can sound quite insane, just reading the title, but I lost 2 days looking for an unbelievable crash, so I want to you to save some time.
My service has a Poco::HttpServer, I use it in windows 7 or grater, in windows server 2012 or grater, on Debian 12 and Debian 13. Thousands of installations, let's say about 2000. I use static library with mt lib version.
Last Fryday I found a new installation on a HP workstation with an Intel Core Ultra Processors (Series 2), that systematically crash after 10 seconds from start.
The crash happens here:

void HTTPServerConnection::run()
{
	std::string server = _pParams->getSoftwareVersion();
	HTTPServerSession session(socket(), _pParams);
	while (!_stopped && session.hasMoreRequests())
	{
		try
		{
			Poco::FastMutex::ScopedLock lock(_mutex);
			if (!_stopped)
			{
				HTTPServerResponseImpl response(session);
				HTTPServerRequestImpl request(response, session, _pParams);

				Poco::Timestamp now;
				response.setDate(now);
				response.setVersion(request.getVersion());
				response.setKeepAlive(_pParams->getKeepAlive() && request.getKeepAlive() && session.canKeepAlive());
				if (!server.empty()) 
					response.set("Server"s, server);  <---- CRASH HERE			

Even at this point the crash reason/line seems unreal, but I did hundreds of try and check. Commenting out that string all goes wel, with that crash. And the funny part is that inside that set function, I end up insert some test code, like this

void NameValueCollection::set(const std::string& name, const std::string& value)
{
        printf("%s\n", name.c_str()); <------CRASH
	Iterator it = _map.find(name);
	if (it != _map.end())
		it->second = value;
	else
		_map.insert(HeaderMap::ValueType(name, value));
}

Ah that printf crash as well because the name variable was "undefined" like a variable out of scope

So after a lot of other tries, just to get to the point, I found that in Porject property page under C/C++ -> Optimization I had to change the last line
Whole Program Optimization from NO to YES
Doing that and recompile library in my code all works grate without crash. The library that way become more space consuming but that do the job. I don't know if it affect just the mt version

[matejk]

Which compiler did you use?

Can I assume that the crash does not happen with dynamic libraries?

[micheleselea]

I use

I have always use static library mt, So I can't say

[matejk]

Do you build Poco with VS project files or with CMake?

One potential issue that I found is that inconsistent usage of link optimisations could lead to crashes on new CPUs.

For example:

• Static libraries built without /GL (Whole Program Optimization)
• Application linking them without /LTCG (Link Time Code Generation)
• Runtime crashes on Lunar Lake, but works on older CPUs

[micheleselea]

I've always compiled with VisualStudio the library and my project
The problem you describe @matejk I think it's exacly my problem. I did not have /GL in my project and in PocoProjects was enable, and that cause a runtime crash on newer CPU.
So basically we are experience the same issue. I don't know if this affect event the md version of lib and/or dll version